Checking for updates slow with IPv6 enabled if 'Prefer IPv4 over IPv6' is not checked

4NVXr3wHBnQYsHwE

traceroute6 goes out to lunch at ae-11.edge5.WashintonDC12.Level3.net whereas v4 proceeds and reaches fw1-zcolo.netgate.com

root: traceroute6 pfsense-plus-pkg00.atx.netgate.com
traceroute6 to pfsense-plus-pkg00.atx.netgate.com (2610:160:11:18::207) from 2606:a000:bfc0:2:b84c:7143:2f47:9c89, 64 hops max, 28 byte packets
 1  * * *
 2  lag-54.grnrnc0711h.netops.charter.com  14.688 ms  28.137 ms  18.051 ms
 3  lag-24.drhmncev02r.netops.charter.com  12.267 ms  13.733 ms *
 4  * * *
 5  lag-12.asbnva1611w-bcr00.netops.charter.com  29.523 ms * *
 6  lag-12.vinnva0510w-bcr00.netops.charter.com  19.093 ms
    lag-22.vinnva0510w-bcr00.netops.charter.com  17.595 ms
    lag-32.vinnva0510w-bcr00.netops.charter.com  17.857 ms
 7  ae-11.edge5.WashintonDC12.Level3.net  29.987 ms  43.889 ms *
 8  * * *
 9  * * *
...

root: traceroute pfsense-plus-pkg00.atx.netgate.com
traceroute to pfsense-plus-pkg00.atx.netgate.com (208.123.73.207), 64 hops max, 40 byte packets
 1  066-026-064-001.inf.spectrum.com (66.26.64.1)  9.989 ms  10.604 ms  26.831 ms
 2  lag-54.grnrnc0711h.netops.charter.com (174.111.103.36)  36.974 ms  35.569 ms  26.734 ms
 3  lag-24.drhmncev02r.netops.charter.com (24.25.62.132)  18.485 ms  11.796 ms  16.078 ms
 4  lag-31.rcr01drhmncev.netops.charter.com (24.93.64.184)  18.166 ms  14.496 ms  13.844 ms
 5  lag-415.asbnva1611w-bcr00.netops.charter.com (107.14.18.106)  16.994 ms
    lag-15.asbnva1611w-bcr00.netops.charter.com (66.109.6.80)  31.212 ms
    lag-12.asbnva1611w-bcr00.netops.charter.com (66.109.10.176)  16.868 ms
 6  lag-22.vinnva0510w-bcr00.netops.charter.com (66.109.3.25)  28.980 ms
    lag-12.vinnva0510w-bcr00.netops.charter.com (66.109.6.31)  19.052 ms  12.205 ms
 7  ae-11.edge5.WashintonDC12.Level3.net (4.68.37.213)  49.540 ms *  21.420 ms
 8  * * *
 9  ZAYO-BANDWI.ear5.Dallas1.Level3.net (4.14.49.2)  68.016 ms  55.914 ms  50.155 ms
10  ae0.aus01-mls-dc-core-a.infr.zcolo.com (64.20.229.158)  66.949 ms  52.707 ms
    ae0.aus01-mls-dc-core-b.infr.zcolo.com (64.20.229.166)  65.401 ms
11  net66-219-34-194.static-customer.corenap.com (66.219.34.194)  62.245 ms  61.453 ms
    net66-219-34-198.static-customer.corenap.com (66.219.34.198)  56.060 ms
12  fw1-zcolo.netgate.com (208.123.73.4)  55.074 ms  49.428 ms  52.096 ms

Gertjan

@4nvxr3whbnqyshwe

[23.01-RELEASE][admin@pfSense.next-to.me]/root: ping -c 3 -6 pfsense-plus-pkg00.atx.netgate.com
PING6(56=40+8+8 bytes) 2a01:cb19:907:a600:92ec:77ff:fe29:392a --> 2610:160:11:18::207
16 bytes from 2610:160:11:18::207, icmp_seq=0 hlim=53 time=133.871 ms
16 bytes from 2610:160:11:18::207, icmp_seq=1 hlim=53 time=136.850 ms
16 bytes from 2610:160:11:18::207, icmp_seq=2 hlim=53 time=132.996 ms

--- pfsense-plus-pkg00.atx.netgate.com ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 132.996/134.572/136.850/1.649 ms

It tend to say : works for me.

'me' is my pfSense 23.01 and everything else needed to have a transparent IPv6 connection to the Internet.
Most ISP's have done a great job for IPv4 : it mostly works.
IPv6 : it's a mess. One ISP implemented it the needed RFC's in mind.
Other didn't do that, or "forgot" to activate their peering - because of $$$$ ? so some destinations work, others ... well ... as said, a mess.

And then there is this new situation : as there is no IPv6 notion of what RFC1918 is, your ISP router could hand over real IPv6 addresses (starting with a '2') to every device that is connected to it.
One of these devices is pfSense, so, fine, it gets an IPv6 assigned.
Your WAN is happy : it now looks like :

WAN (wan)       -> ix3        -> v4/DHCP4: 192.168.10.4/24
                                 v6/DHCP6: 2a01:cb19:907:a600:dead:beef:fe29:39

But pfSense wants more, it also needs a so called /64 for each LAN.
For example :
I've a
2a01:cb19:907:a601:0:0:0:1 ->2a01:cb19:907:a601:0:0:0:ffff (an entire /64 as 0:0:0:1 to 0:0:0:ffff is a /64) for my first LAN.
2a01:cb19:907:a602:0:0:0:1 ->2a01:cb19:907:a602:0:0:0:ffff (an entire /64 as 0:0:0:1 to 0:0:0:ffff is a /64) for my second LAN.

My ISP gives 'me' a /56 , so I can have 256 (one or two less, though) /64 blocks (prefixes) numbered 01 to 255 ($ff).
These prefixes, like 2a01:cb19:907:a601::/64 on my LAN, can be sued by the dhcp6d server so it can hand out IPv6 (the ones started with '2', as these are routable).

IPv6 is not plug and play when you chain routers up one after another.

SteveITS

@4nvxr3whbnqyshwe said in Checking for updates slow with IPv6 enabled if 'Prefer IPv4 over IPv6' is not checked:

traceroute6 goes out to lunch at ae-11.edge5.WashintonDC12.Level3.net

Though it may seem unlikely, it's possible there's a routing/peering issue at level3.net. I've seen cases where IPv6 had packet loss and IPv4 did not.

4NVXr3wHBnQYsHwE

I had the same thought. I tried using Centurylinks (I guess L3,Lumen,Centuylink are all the same now) looking glass site to try making sense of it, but frustratingly it doesn't seem to provide a response for any ipv6 address, even though it appears it should accept one: https://lookingglass.centurylink.com/

I've tried from HE and some other looking glass servers and haven't spotted anywhere the pkg server doesn't respond from. It's frustrating that I can't seem to find anything else that doesn't work for me to indicate a problem here, or anywhere else that the pkg server isn't reachable to indicate a problem elsewhere.

I'm a very light user of IPv6, having mostly turned it on to educate myself. I haven't paid IPv6 much mind in quite awhile, and have had no problem until the last few days. In the end I can prefer IPv4 and work around the problem and not be missing much.

Gertjan

@4nvxr3whbnqyshwe said in Checking for updates slow with IPv6 enabled if 'Prefer IPv4 over IPv6' is not checked:

I've tried from HE ...

I've been using their IPv6 for a long time.
'Speed' wasn't an issue for me, just the IPv6 connectivity. They are ... well ... I guess they invented IPv6. They really 'own' all the cables all over the globe.

With this setup : Configuring IPv6 Through A Tunnel Broker Service your IPv6 is 100 % on your side. Because you use a IPv6 tunnel over IPv4, your IPv6 connection will be 100 % - I never, the last 10 years or so (?), had issues with my 'pkg' (pfSense) or any other LAN IPv6 device.
More then half of all my traffic (company) is IPv6 these days - as my ISP finally 'supports' IPv6.
If the he.net connection works, but not your ISP, then probably your ISP -or whatever lies behind them, is to blame.

But again, as I've shown in my previous post, IPv6 is more as 'select IPv6' on WAN and your done.
the thing is : if pfSEnse 'thinks' is has an IPv6 connection on it's WAN, and because all OSs prefer be far IPv6 over IPv4, it will use IPv6.
The "will fall back to IPv4 if IPv6 doesn't work out / time outs" isn't always the case.
'pkg' (pfSense) is probably a good example here.

stephenw10

Yes, this should work fine over IPv6:

[23.05-DEVELOPMENT][admin@fw1.stevew.lan]/root: pkg -6 update
Updating pfSense-core repository catalogue...
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
pfSense repository is up to date.
All repositories are up to date.

But, yes, it will try to use IPv6 if it thinks it has a route but something is broken. And that can be a problem.

Steve

orien

I'm so glad you posted this! I just noticed this exact issue pop up in the last week or so. I'm also on Spectrum and preferring ipv4 does indeed resolve it for me as well.

4NVXr3wHBnQYsHwE

@orien Thanks for confirming I'm not completely crazy. I tried contacting Spectrum support once and it yielded less positive results than chewing on broken glass.

I found a Lumen/L3 email address via whois yesterday and fired off a quick message. I am not expecting much, but maybe they can diagnose and correct it.

It was also suggested elsewhere to maybe contact Netgate support since they operate their own ASN and it could be an issue between them/zcolo and L3/Lumen. I have not made this effort yet and I do not know how receptive they would be to investigating it.

Someone on the Reddit thread I created said they had a similar problem with AT&T Fiber, so while anecdotal evidence suggests few folks are affected, it does not seem restricted to Spectrum.

https://www.reddit.com/r/ipv6/comments/1308p7n/cant_access_ipv6_address_for_pfsense_package/

4NVXr3wHBnQYsHwE

Someone on Reddit was able to get in touch with Spectrum Enterprise Tech Support and get this fixed for them. It is fixed for me now as well.

https://www.reddit.com/r/ipv6/comments/1308p7n/comment/jillrhc/?utm_source=share&utm_medium=web2x&context=3

stephenw10

It's a miracle!