Massive HTTP IPv6 connectivity issues
-
Hmmm - So your configuration is very complex?
-
@G.D.:
I haven't had a single problem - Makes me wonder what we are doing differently.
You do not have my uplinks, that is what different. LOL
It looks like I can make the IPv6 websites browsing working by setting MSS on the pfSense IPv6 interface to 1220.
thanks! I try setup MSS to 1220, just work.. ;D
-
I've had similar problems running dual-stack with IPv6 through HE.net tunnelbroker, and a routed /48. HTTPS breaks, seems it can't get past the TLS handshake.
Oddly, some ipv6 sites always work perfectly, ipv6 test sites, Google, but lots of other HTTPS sites do not (Netflix, forum.pfsense.org).
The thing is it was working flawlessly for a while with the MTU field blank on my inside LAN interface, but I had to drop MTU to 1280 to get it working again, so I suspect that someone might be filtering ICMP messages along the way, or <nsa>doing ssl decrypt poorly</nsa>.
I will also try MSS suggestion to see if that helps.–
Andrew -
Probably trying to tunnel IPv6 over something that's already tunneling or something. That second tunnel might be something out in the ISP network somewhere, unbeknownst to the user.
I wish more sites would add a little logo somewhere if you're hitting them over IPv6. I have no idea when I'm using it and when I'm not. Hmm. 6orNot firefox add-on FTW.
-
I leave the HE tunnel up on the pfsense dashboard so I can see when bandwidth is being pulled through it occasionally.
netflix for sure as well as youtube and anything google related defaults to it 100% of time with no issues.
-
Right, which makes sense, modern OSes are supposed to prefer IPv6 over IPv4 when both are available.
IPv6 also removes all NAT issues, so that's not what's causing the problem here.
What I don't understand, is what is Google doing that is different than Netflix to the point where it never fails over IPv6 when Netflix can't successfully negotiate a TLS handshake to start up a web page???
It is almost as if something is doing ICMP filtering and blocking path MTU discovery (like security n00bs were doing at ISPs years ago by blocking ALL ICMP). I'm pretty sure its not the pfSense because I specifically allow IPv6 ICMP messages, and I'd be surprised if HE.net was filtering ICMP, but with another link that is native dual-stack (ie: not going through a tunnel broker), these issues do not occur.–
Andrew -
Right, which makes sense, modern OSes are supposed to prefer IPv6 over IPv4 when both are available.
I'm pretty torqued at Apple for implementing RFC6555 "Happy Eyeballs" with no way to disable it.
For instance, I never use IPv6 to connect to this site. I want to know when IPv6 is shaky.
-
I'm pretty torqued at Apple for implementing RFC6555 "Happy Eyeballs" with no way to disable it.
For instance, I never use IPv6 to connect to this site. I want to know when IPv6 is shaky.
Maybe you can disable IPv4 all together? On Windows it is easy to flip IPv4 on and off, no restart required.
-
I don't think IPv6 is quite there yet. :/
"Happy Eyeballs" seems to have been tweaked in 10.9.5. I'm seeing a lot more green sixes in 6orNot after updating. (Including this site right now. :)
-
This issue occurs when the connection is a PPPoE from provider, this type of connection is almost always MTU 1480 (just look at the router/modem manual).
It seems to work if you let the WAN interface MTU Blank (which usually assumes 1500 bytes, as in any normal Ethernet link), but causes in some cases the issues mentioned in this thread.
It's better not to set MSS in the LAN interface and yes, set ONLY the MTU in the WAN(s) interface(s) AS RECOMMENDED by the provider.
On pfSense:
-
This thread was 6 years old fyi.
