Checking for updates slow with IPv6 enabled if 'Prefer IPv4 over IPv6' is not checked
-
I noticed last night that checking for updates is running extremely slow on my pfSense system.
The Web UI is timing out after a few minutes when checking for updates or listing installed packages. Using option 13 on the console works but takes several minutes to complete.
I just checked 'Prefer IPv4 over IPv6' and now option 13 completes in just a few seconds and I can readily recreate the problem by unchecking the option again.
Has anyone seen this before? As far as I known it hasn't been going on long. I am pretty diligent about checking for package updates at least once a week. And I can't think of any recent changes to the system that I might have made to cause this. I'm curious what might be causing this and how to fix it.
FWIW, I've confirmed that I can (still) reach IPv6 sites with my laptop, I can ping IPv6 addresses from the pfSense console and my ISP is Spectrum.
-
Despite being able to reach and browse other sites via IPv6 I seem to be unable to reach the pfsense pkg server over ipv6. I found a few online sites that let you perform a ping6 from a remote system and contrary to my result they seem to have no problem. Not really sure what to make of it.
$ ping -c 3 -6 www.redhat.com PING www.redhat.com(g2600-1408-c400-188d-0000-0000-0000-0d44.deploy.static.akamaitechnologies.com (2600:1408:c400:188d::d44)) 56 data bytes 64 bytes from g2600-1408-c400-188d-0000-0000-0000-0d44.deploy.static.akamaitechnologies.com (2600:1408:c400:188d::d44): icmp_seq=1 ttl=53 time=23.5 ms 64 bytes from g2600-1408-c400-188d-0000-0000-0000-0d44.deploy.static.akamaitechnologies.com (2600:1408:c400:188d::d44): icmp_seq=2 ttl=53 time=25.5 ms 64 bytes from g2600-1408-c400-188d-0000-0000-0000-0d44.deploy.static.akamaitechnologies.com (2600:1408:c400:188d::d44): icmp_seq=3 ttl=53 time=23.2 ms --- www.redhat.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 23.191/24.060/25.533/1.046 ms$ ping -c 3 -6 www.apple.com PING www.apple.com(g2600-1408-c400-1882-0000-0000-0000-1aca.deploy.static.akamaitechnologies.com (2600:1408:c400:1882::1aca)) 56 data bytes 64 bytes from g2600-1408-c400-1882-0000-0000-0000-1aca.deploy.static.akamaitechnologies.com (2600:1408:c400:1882::1aca): icmp_seq=1 ttl=53 time=30.8 ms 64 bytes from g2600-1408-c400-1882-0000-0000-0000-1aca.deploy.static.akamaitechnologies.com (2600:1408:c400:1882::1aca): icmp_seq=2 ttl=53 time=33.3 ms 64 bytes from g2600-1408-c400-1882-0000-0000-0000-1aca.deploy.static.akamaitechnologies.com (2600:1408:c400:1882::1aca): icmp_seq=3 ttl=53 time=33.8 ms --- www.apple.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 30.766/32.631/33.843/1.338 ms$ ping -c 3 -6 www.microsoft.com PING www.microsoft.com(g2600-1408-c400-078c-0000-0000-0000-356e.deploy.static.akamaitechnologies.com (2600:1408:c400:78c::356e)) 56 data bytes 64 bytes from g2600-1408-c400-078c-0000-0000-0000-356e.deploy.static.akamaitechnologies.com (2600:1408:c400:78c::356e): icmp_seq=1 ttl=53 time=27.0 ms 64 bytes from g2600-1408-c400-078c-0000-0000-0000-356e.deploy.static.akamaitechnologies.com (2600:1408:c400:78c::356e): icmp_seq=2 ttl=53 time=32.6 ms 64 bytes from g2600-1408-c400-078c-0000-0000-0000-356e.deploy.static.akamaitechnologies.com (2600:1408:c400:78c::356e): icmp_seq=3 ttl=53 time=30.0 ms --- www.microsoft.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 26.951/29.866/32.601/2.310 ms$ ping -c 3 -6 www.google.com PING www.google.com(bi-in-f147.1e100.net (2607:f8b0:4004:c08::93)) 56 data bytes 64 bytes from bi-in-f147.1e100.net (2607:f8b0:4004:c08::93): icmp_seq=1 ttl=104 time=22.0 ms 64 bytes from bi-in-f147.1e100.net (2607:f8b0:4004:c08::93): icmp_seq=2 ttl=104 time=25.7 ms 64 bytes from bi-in-f147.1e100.net (2607:f8b0:4004:c08::93): icmp_seq=3 ttl=104 time=21.2 ms --- www.google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 21.182/22.955/25.675/1.952 ms$ ping -c 3 -6 pfsense-plus-pkg00.atx.netgate.com PING pfsense-plus-pkg00.atx.netgate.com(2610:160:11:18::207) 56 data bytes --- pfsense-plus-pkg00.atx.netgate.com ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2053ms$ ping -c 3 -4 pfsense-plus-pkg00.atx.netgate.com PING (208.123.73.207) 56(84) bytes of data. 64 bytes from 208.123.73.207 (208.123.73.207): icmp_seq=1 ttl=49 time=61.2 ms 64 bytes from 208.123.73.207 (208.123.73.207): icmp_seq=2 ttl=49 time=61.8 ms 64 bytes from 208.123.73.207 (208.123.73.207): icmp_seq=3 ttl=49 time=70.5 ms --- ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 61.177/64.468/70.475/4.254 ms -
@4nvxr3whbnqyshwe Ive seen this sort of thing posted before. IIRC it’s usually when a name resolves to IPv6 but IPv6 is broken. I wasn’t clear ,are you pinging from pfSense? There is a ping test on the Diagnostics menu.
-
@steveits The above examples are from a laptop behind the netgate.
But I'm seeing similar from the netgates CLI, with a few examples below. I haven't managed to find another site that doesn't work other than
pfsense-plus-pkg00.atx.netgate.comand I'm trying to understand why this one server isn't working for, so far as I can tell so far, just me.root: ping -c 3 -6 pfsense-plus-pkg00.atx.netgate.com PING6(56=40+8+8 bytes) 2606:a000:bfc0:2:b84c:7143:2f47:9c89 --> 2610:160:11:18::207 --- pfsense-plus-pkg00.atx.netgate.com ping6 statistics --- 3 packets transmitted, 0 packets received, 100.0% packet lossroot: ping -c 3 -6 www.google.com PING6(56=40+8+8 bytes) 2606:a000:bfc0:2:b84c:7143:2f47:9c89 --> 2607:f8b0:4002:802::2004 16 bytes from 2607:f8b0:4002:802::2004, icmp_seq=0 hlim=117 time=29.802 ms 16 bytes from 2607:f8b0:4002:802::2004, icmp_seq=1 hlim=117 time=24.452 ms 16 bytes from 2607:f8b0:4002:802::2004, icmp_seq=2 hlim=117 time=21.150 ms --- www.google.com ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 21.150/25.135/29.802/3.565 msroot: ping -c 3 -4 pfsense-plus-pkg00.atx.netgate.com PING pfsense-plus-pkg00.atx.netgate.com (208.123.73.207): 56 data bytes 64 bytes from 208.123.73.207: icmp_seq=0 ttl=50 time=58.520 ms 64 bytes from 208.123.73.207: icmp_seq=1 ttl=50 time=58.165 ms 64 bytes from 208.123.73.207: icmp_seq=2 ttl=50 time=65.285 ms --- pfsense-plus-pkg00.atx.netgate.com ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 58.165/60.657/65.285/3.276 ms -
traceroute6 goes out to lunch at
ae-11.edge5.WashintonDC12.Level3.netwhereas v4 proceeds and reachesfw1-zcolo.netgate.comroot: 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 -
[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 msIt 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:39But 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.
-
@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.
-
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.
-
@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. -
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
-
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.
-
@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/
-
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
-
It's a miracle!
