6rd Tunnel with AT&T Uverse IPv6
-
I am unable to get this to work in my setup. I have a 589 and have followed the directions to a t. My WAN_6RD gateway is offline and I can't ping. The only time I saw it come online was while the 589 was rebooting. But as soon as it finished booting the gateway went offline. I'm guessing that only one IP address can contact the border relay and since the 589 is always going to attempt, the 589 overrides. Oh well, fingers crossed for HE tunnels or something else to come back!
-
The nature of how 6rd works, only one tunnel can exist per public IP that you have. The v6 gateway IP is never pingable on AT&T 6rd (and likely most if not all other providers).
If you have one of the 2wire RG boxes as your modem, recent firmware versions on it block IP protocol 41 including their own 6rd. Apparently no way to work around that. That also breaks HE.net tunnels.
-
So it turns out it was working the whole time, just like stated above the Gateway does not respond to pings. Now i just need to figure out DHCPv6 and how to come up with a range and then all will be good!
-
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 ServerIf 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 serverTesting 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.
-
6rd tunnels (he.net) now work with att. They are no longer blocking protocol 41.
-
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 are6rd prefix: 2602:300::/28
6rd Border Relay:12.83.49.81
6rd IPv4 Prefix length: 0 bitsI'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?
-
I had an HE tunnel up and running but i still experienced an MTU issue. Something is messed up somewhere.
-
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).
-
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 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.
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
-
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 MTUIf 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.
-
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* 1PS 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* 4Note: Using ethernet at the time I checked the MTU. Wifi was turned off.
-
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.
-
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.
-
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?
-
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 -
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.
