Changing AdvLinkMTU when using NPt
-
First of all, I did not hardcode any MTU on any interface
I did some more investigation, and on the pfsense level, the MTU negotiation is fine:
wan_stf: flags=4041 <up,running,link2>metric 0 mtu 1280
inet6 2a02:xxxx:xxx:xxx:: prefixlen 32
nd6 options=1 <performnud>v4net xxx.x.xx.xx/32 -> tv4br xxx.xxx.xxx.xxx
groups: stfThe problem is that radvd is either taking 1500 or the MTU of the LAN interface (which end up being 1500 in my case). I did some wireshark and saw no packet too bit.
How is it meant to be working? Should pfsense advertise the correct MTU? Should the client be able adjust on packet too big? Who would issue the packet too big (pfsense, 6RD GW, …) ?</performnud></up,running,link2>
-
PfSense should be advertising the MTU of the local link only, not any other interface. So, even if your tunnel is only 1280, the local link is 1500. IPv6 will then use Path MTU Discovery to set the MTU for any traffic passing through that tunnel. So, if you look at packets going through the tunnel, you should see an MTU of 1280. You can capture the packets with Packet Capture, but will have to export to Wireshark to see the MTU. If you capture everything, you can see PMTUD in action.
-
First of all, I did not hardcode any MTU on any interface
I didnt say you did, I said pfSense does on 6RD interfaces.
The problem is that radvd is either taking 1500 or the MTU of the LAN interface (which end up being 1500 in my case). I did some wireshark and saw no packet too bit.
That is not a problem, that is exactly what it is supposed to do.
How is it meant to be working? Should pfsense advertise the correct MTU? Should the client be able adjust on packet too big? Who would issue the packet too big (pfsense, 6RD GW, …) ?
pfSense is advertising the correct MTU for the Ethernet LAN, 1500, again that is what it is supposed to do.
When pfSense receives a packet that need to be forwarded though the 6RD interface with an MTU of 1280 that is larger then that it will send a ICMNPv6 Type 2 (Packet to big) message with the MTU that should be used, the client will then resend its packets to that destination with the new MTU. If you block All ICMP or those messages the connection will fail if any packets are over the MTU of the link.
Also really 6rd does not have an automatic MTU of 1280, pfSense just sets it that way for some reason. 6rd MTU can be upto:
(Your WAN MTU) - 20 = (6RD MTU)Also NPt has NOTHING to do with MTU at all.
-
^^^^
Where's this 6rd coming from? I thought the OP was talking about he.net, which uses 6in4 over a configured tunnel. 6rd is a method used by some ISPs to provide IPv6, using the ISPs IPv4 addresses. While both methods use a tunnel for IPv6, the set up is quite different. -
^^^^
Where's this 6rd coming from? I thought the OP was talking about he.net, which uses 6in4 over a configured tunnel. 6rd is a method used by some ISPs to provide IPv6, using the ISPs IPv4 addresses. While both methods use a tunnel for IPv6, the set up is quite different.Op was using a GIF INterface and I assume he.net tunnel.
FuN_KeY is using 6rd.
-
AC3200 is acting as my main gateway, and I want to use it as DHCP server for local and VPN clients.
If they were using 6rd, there'd be no need for he.net. Either method creates an IPv6 tunnel, but you wouldn't use both. So, it's either 6rd or he.net. Take your pick.
-
I was able to capture the packet too big on wireshark. Everything looks good, except for my Windows 10 client that appear to ignore this value.
-
I was able to capture the packet too big on wireshark. Everything looks good, except for my Windows 10 client that appear to ignore this value.
So, it continues to send 1500 byte packets, despite the too big message? I certainly never had a problem running Windows on IPv6, back when I used a tunnel.
-
I was able to capture the packet too big on wireshark. Everything looks good, except for my Windows 10 client that appear to ignore this value.
So, it continues to send 1500 byte packets, despite the too big message? I certainly never had a problem running Windows on IPv6, back when I used a tunnel.
Agreed,, I have never had an issues with PMTUD on Winows since XP..
-
I was able to capture the packet too big on wireshark. Everything looks good, except for my Windows 10 client that appear to ignore this value.
Any 3rd party firewall?/security software? Have you made any canges to the windows firewall.
-
Nope, vanilla windows 10 (tested on the host and in a VM with a fresh windows install)
I did attach 2 captures. In the first one, one can see the packet too big. And in the second you can see some errors beyond my basic understanding of wireshark.
I did filter the capture over traffic towards a web site (www.swisscom.ch) + icmpv6. Sadly the website I am having problem with uses SSL, so the capture is not that clear.
If I edit the services.inc to let radvd advertise a MTU of 1280 (or even 1480 - despite the 6RD being configured to use 1280) everything works fine.
 -
I haven't seen those errors before either, however it appears something might be corrupting the Ethernet frames. There's the malformed packet error, which means there was a problem somewhere causing bit errors in the frame. That might also be the cause of the segment errors. There's not enough info shown to know where the problem is coming from. Do other computers have the same problem? If only one has the problem, I'd suspect something like a defective NIC. The 1480 MTU shows PMTUD is working. What other equipment is there between the Windows computer and pfSense? Again those malformed packet, frame check sequence incorrect errors make me suspect hardware.
-
I just thought of something to. Is that the only site you have an issue with when you let it advertised a 1500 MTU. Because I noticed something from that site when I ran a certain test to it. I'll link and show it in a minute when I get a chance
-
I just thought of something to. Is that the only site you have an issue with when you let it advertised a 1500 MTU. Because I noticed something from that site when I ran a certain test to it. I'll link and show it in a minute when I get a chance
The site shouldn't cause Ethernet frame errors, as he appears to be getting.
-
I just thought of something to. Is that the only site you have an issue with when you let it advertised a 1500 MTU. Because I noticed something from that site when I ran a certain test to it. I'll link and show it in a minute when I get a chance
The site shouldn't cause Ethernet frame errors, as he appears to be getting.
Agreed. But I'm wondering if there's not two issues and while that is of course a problem maybe not the problem for that site.
See this
https://www.ipv6alizer.se?address=https://www.swisscom.ch
Vs
https://www.ipv6alizer.se?address=https://Www.facebook.com -
Wow, the "Output" on that site is impossible to read, with the faint green text. I had to cut 'n paste it into another app, to read it. Why do some people create sites that are unreadable?
-
Yep this is strange. I did some more testing, and I am also getting weird errors when I set router advertisement to 1280 (but traffic works, beside wireshark, everything is green)
I am unsure about bad hardware, as ipv4 works fine. Pretty much everything runs on VMs, on intel NICs. As IPv6 is not vital and that I do not see any easy way to get this sorted I might not invest too much effort in getting this working. In any case, I will report my findings here
In any case, thank everyone for the help.
-
Yep this is strange. I did some more testing, and I am also getting weird errors when I set router advertisement to 1280 (but traffic works, beside wireshark, everything is green)
I am unsure about bad hardware, as ipv4 works fine. Pretty much everything runs on VMs, on intel NICs. As IPv6 is not vital and that I do not see any easy way to get this sorted I might not invest too much effort in getting this working. In any case, I will report my findings here
In any case, thank everyone for the help.
You never mentioned if this effects any other site. Other then that one.
-
I am unsure about bad hardware, as ipv4 works fine.
If you're getting CRC errors, you have a hardware problem that has nothing to do with IP or web site. It could be a bad NIC, switch port, cable connection, etc., but something physical is causing that. Are you certain you don't see any similar errors with IPv4? You can try pinging with different size packets to test and you can also force either IPv4 or IPv6 when testing. Do you get similar errors if you use a different computer?
-
I know it old topic, but @JKnott test yourself https://meet.lync.com/ not adjusted at all
