What am I looking for exactly? I tried disabling IPv6 from Linux Mint's network manager, and while ifconfig doesn't show an inet6 entry anymore, the problem with github and posting on this forum, among others, persists.
Well, GitHub seems to work for you with cURL.
So, try to use another browser.
Try to enable/disable DNS over HTTPS in the browser.
That is so weird. I can in fact load the homepage of github.com on Google Chrome. I can't login though, I get a timeout. DNS over HTTPS is already disabled. Enabling it doesn't change anything.
tcpdump -i br-lan -evn 'icmp6 && ip6[40] == 136'
This will show the RAs. But it is not connected to your problem with github.
Here's the result of tcpdump:
sudo tcpdump -i enp3s0 -evn 'icmp6 && ip6[40] == 136'
tcpdump: listening on enp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:30:22.832631 3a:19:88:66:78:88 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::c473:a9a6:7822:7e53 > ff02::1: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is fe80::c473:a9a6:7822:7e53, Flags [override]
destination link-address option (2), length 8 (1): 3a:19:88:66:78:88
12:31:30.333770 d8:cb:8a:f1:fa:00 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::dd8b:2a78:cfbb:f920 > ff02::1: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is fe80::dd8b:2a78:cfbb:f920, Flags [override]
destination link-address option (2), length 8 (1): d8:cb:8a:f1:fa:00
I also found this post that corresponds to my problem. I tried the fix described by changing the MTU for enp3s0 to 1420, but the problem persists. I do experience the exact same symptoms though, even the Frag needed and DF set (mtu = 1420) message on pings.
1 Like
136 is the neighbour advertisement, 134 is the router. Sorry my bad. Try to run it again and compare the sending mac address with the mac of the router.
You don't need to change the MTU of the PC adapter. Leave it 1500 as the br-lan is.
The wireguard tunnel has already MTU 1420.
Ask your VPN provider if 1420 is the right value.
I finally have a solution. Setting the MTU to 1380 in the WireGuard interface solves the problem. Bloody hell was this difficult to troubleshoot. Thank you so much for your help, trendy, I really appreciate it. I learned a bunch of things about networking along the way, so this wasn't entirely pointless 
I'll leave the IPv6 as it is since it doesn't cause any issues.
2 Likes
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.