6rd Tunnel with AT&T Uverse IPv6

azzido

When I was testing AT&T IPv6 I discovered that if 6rd tunnel is terminated on pfSense IPv6 download speed can be considerably lower than IPv4 download speed:


IPv4    IPv4        IPv4        IPv6    IPv6        IPv6
ms      Down Mbps   Up Mbps     ms      Down Mbps   Up Mbps
22      50.00       5.58        21      20.42       5.26        Chicago Server
53      32.14       5.46        55      20.07       5.35        Denver Server
48      39.20       5.46        62      17.67       5.40        Boston Server

If 6rd is terminated on NVG589 and IPv6 on pfSense WAN is set to DHCP, then IP v6 and v4 speeds are comparable:


IPv4    IPv4        IPv4        IPv6    IPv6        IPv6
ms      Down Mbps   Up Mbps     ms      Down Mbps   Up Mbps
21      50.27       5.63        20      48.77       5.64        Chicago server
53      42.56       5.58        58      48.25       5.44        Denver server
48      46.08       5.64        61      47.59       5.42        Boston server

Testing was being done using http://speedtest.comcast.net

This is a known issue and does not have anything to do with pfSense. You can read more about it here http://www.dslreports.com/forum/r29436224-UVERSE-IPv6-Problems. It is not clear if the issue lies with NVG589 or 6rd endpoints.

icemanncsu, since you are one of those unique people that are using AT&T without NVG589, could you run Comcast speed test and report if you are seeing speed difference between IPv6 and IPv4.

ortizdr

6rd tunnels (he.net) now work with att. They are no longer blocking protocol 41.

CynicalFrost

I'm having some strange IPv6 connectivity issues with my setup where connections to random IPv6 enabled sites are flaky and take forever to load (if they do before I stop loading the page after like 3 minutes).

Setup:
I have a Motorola NVG589 set in "bridge" mode and have pfSense handling the 6rd tunneling where my settings for the WAN port are

6rd prefix: 2602:300::/28
6rd Border Relay:12.83.49.81
6rd IPv4 Prefix length: 0 bits

I've also configured several LAN ports to track the WAN interface, assigning each a Prefix ID from 0 to 5.

I suspected that it might be a MTU issue, but after trying various combinations and test cases, I'm not so sure anymore.

Is anyone else having similar issues?

ortizdr

I had an HE tunnel up and running but i still experienced an MTU issue. Something is messed up somewhere.

dem

@CynicalFrost:

I suspected that it might be a MTU issue, but after trying various combinations and test cases, I'm not so sure anymore.

I see similar issues unless I force router advertisements to send 1280 for the MTU (edit /var/etc/radvd.conf and change AdvLinkMTU to 1280, then send a SIGHUP to radvd).

azzido

CynicalFrost, i had similar issues and most of them were caused by MTU size being too large. Your best bet is to change MTU on your PC to 1472 and see if the issue persists.

The whole MTU thing is a bit convoluted. If you change radvd config file directly, it will revert back to the interface MTU size on pfSense if something changes on the firewall and config file is regenerated. Your only reliable option here is to patch PHP code that generates radvd config file.

If you change MTU size on the pfSense interface, but leave MTU on your client unchanged you will run into problems with IPv4 traffic that comes in with do not fragment flag set. One thing to keep in mind is that Linux and Windows has separate MTU settings for IPv4 and IPv6 and you can set them independently, but FreeBSD (as far as I know) only has one setting that applies to both IPv4 and IPv6. If you reduce MTU size on pfSense interface you also need to reduce IPv4 MTU size on client machines manually, because RA advertisements only affect IPv6 MTU size.

CynicalFrost

@ortizdr:

I had an HE tunnel up and running but i still experienced an MTU issue. Something is messed up somewhere.

Funny enough, when I setup an HE tunnel, it works without issue without having to adjust the MTU.

@azzido:

CynicalFrost, i had similar issues and most of them were caused by MTU size being too large. Your best bet is to change MTU on your PC to 1472 and see if the issue persists.

The whole MTU thing is a bit convoluted. If you change radvd config file directly, it will revert back to the interface MTU size on pfSense if something changes on the firewall and config file is regenerated. Your only reliable option here is to patch PHP code that generates radvd config file.

If you change MTU size on the pfSense interface, but leave MTU on your client unchanged you will run into problems with IPv4 traffic that comes in with do not fragment flag set. One thing to keep in mind is that Linux and Windows has separate MTU settings for IPv4 and IPv6 and you can set them independently, but FreeBSD (as far as I know) only has one setting that applies to both IPv4 and IPv6. If you reduce MTU size on pfSense interface you also need to reduce IPv4 MTU size on client machines manually, because RA advertisements only affect IPv6 MTU size.

I've done some variation of this recommendation. I've changed the MTU value within pfSense to 1450 for my LAN port (leaving the MTU for WAN port at 1500) and then disabled/re-enabled my ethernet adapter in Windows so that the MTU values gets reset properly. I've double checked the MTU values in windows after disabling/re-enabling and both IPv4 and IPv6 have values set to 1450 (which should be more than enough). I still wind up with connection issues.

I'd rather not rely on setting the MTU value on my PC since I have other devices (tablet, phone) that don't give me that option.

I'm tempted to just forget the 6rd and just use HE, but I feel like that's inefficient

azzido

Never heard of IPv4 MTU adjusting itself automatically. Use below commands to check MTU size on Windows.


netsh interface ipv4 show interfaces       Show IPv4 MTU
netsh interface ipv6 show interfaces       Show IPv6 MTU

If you use Firefox you can easily disable IPv6 by going to 'about:config' and setting 'network.dns.disableIPv6' to true. So whenever you are having issues quickly disable IPv6 and see if the issue goes away. You can also install IPvFox add-on that will tell you what IPs each website is accessing.

CynicalFrost

I take back the MTU for IPv4 adjusting. I thought it had when I ran those commands the last time I tested things out.

anyway, results as requested:

PS C:\Users\alex> netsh interface ipv4 show subinterface

MTU MediaSenseState Bytes In Bytes Out Interface
–---- --------------- --------- --------- -------------
1500 1 611662 1532564 Ethernet
1500 5 0 0 Wi-Fi
4294967295 1 0 29698 Loopback Pseudo-Interface 1
1500 5 0 0 Local Area Connection* 1

PS C:\Users\alex> netsh interface ipv6 show subinterface

MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
1450 1 769901 125344 Ethernet
1500 5 0 298 Wi-Fi
1280 5 0 0 isatap.mydomain.com
4294967295 1 0 24172 Loopback Pseudo-Interface 1
1500 5 0 225 Local Area Connection* 1
1280 1 912 2191 Local Area Connection* 4

Note: Using ethernet at the time I checked the MTU. Wifi was turned off.

azzido

I did forget to mention one thing. Even if you change MTU on your PC, whenever new RA message arrives that advertises MTU size, Windows will update IPv6 MTU.

Thus to properly test if the MTU size is causing issues you need to change MTU on pfSense LAN interface, which will force radvd to advertise new MTU and Windows to update IPv6 MTU size and change MTU on Windows interface which will change IPv4 MTU.

This is one of the reasons why I ditched AT&T IPv6 at home.

CynicalFrost

@azzido:

I did forget to mention one thing. Even if you change MTU on your PC, whenever new RA message arrives that advertises MTU size, Windows will update IPv6 MTU.

Thus to properly test if the MTU size is causing issues you need to change MTU on pfSense LAN interface, which will force radvd to advertise new MTU and Windows to update IPv6 MTU size and change MTU on Windows interface which will change IPv4 MTU.

This is one of the reasons why I ditched AT&T IPv6 at home.

Right. I realized this when I was testing earlier and found that my IPv6 MTU kept getting reset to a higher value when I set the MTU locally until I set it for the LAN interface.

So far, I'm not having much luck with reliable IPv6 connectivity and may just ditch trying to use the 6rd tunnel. I did test out using a HE tunnel and that did seem more reliable so I might go with that.

martylavender

I know there has been no traffic on this post for quite a while but I was intrigued by this post.

I have Uverse Gigapower and am currently using the NVG599 RG for Internet. Is it in fact possible to dump the gateway and connect my pfSense box up and have it masquerade as the RG?

ortizdr

@martylavender:

I know there has been no traffic on this post for quite a while but I was intrigued by this post.

I have Uverse Gigapower and am currently using the NVG599 RG for Internet. Is it in fact possible to dump the gateway and connect my pfSense box up and have it masquerade as the RG?

This has in fact been discussed multiple times over at DSLreports.com
https://www.dslreports.com/forum/r29903721-AT-T-Residential-Gateway-Bypass-True-bridge-mode

martylavender

LOL I was actually just reading through that same post. Seems pretty interesting. I have the old version of the Netgear switch theyre talking about. It has since died. Wonder if I can RMA it! :P Otherwise, I need to pick up a new switch anyway.