Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved General pfSense Questions
    14 Posts 5 Posters 1.2k Views 5 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • 4 Offline
      4NVXr3wHBnQYsHwE
      last edited by

      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
      
      1 Reply Last reply Reply Quote 0
      • S Offline
        SteveITS Rebel Alliance @4NVXr3wHBnQYsHwE
        last edited by

        @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.

        Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
        When upgrading, allow 10-15 minutes to reboot, or more depending on packages, and device or disk speed.
        Upvote 👍 helpful posts!

        4 1 Reply Last reply Reply Quote 0
        • 4 Offline
          4NVXr3wHBnQYsHwE @SteveITS
          last edited by

          @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.com and 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 loss
          
          root: 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 ms
          
          root: 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
          
          4 1 Reply Last reply Reply Quote 0
          • 4 Offline
            4NVXr3wHBnQYsHwE @4NVXr3wHBnQYsHwE
            last edited by

            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
            
            GertjanG S 2 Replies Last reply Reply Quote 0
            • GertjanG Offline
              Gertjan @4NVXr3wHBnQYsHwE
              last edited by

              @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.

              No "help me" PM's please. Use the forum, the community will thank you.
              Edit : and where are the logs ??

              1 Reply Last reply Reply Quote 0
              • S Offline
                SteveITS Rebel Alliance @4NVXr3wHBnQYsHwE
                last edited by

                @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.

                Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
                When upgrading, allow 10-15 minutes to reboot, or more depending on packages, and device or disk speed.
                Upvote 👍 helpful posts!

                4 1 Reply Last reply Reply Quote 0
                • 4 Offline
                  4NVXr3wHBnQYsHwE @SteveITS
                  last edited by

                  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.

                  GertjanG 1 Reply Last reply Reply Quote 0
                  • GertjanG Offline
                    Gertjan @4NVXr3wHBnQYsHwE
                    last edited by

                    @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.

                    No "help me" PM's please. Use the forum, the community will thank you.
                    Edit : and where are the logs ??

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S Offline
                      stephenw10 Netgate Administrator
                      last edited by

                      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

                      1 Reply Last reply Reply Quote 0
                      • O Offline
                        orien
                        last edited by

                        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.

                        4 1 Reply Last reply Reply Quote 0
                        • 4 Offline
                          4NVXr3wHBnQYsHwE @orien
                          last edited by

                          @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/

                          1 Reply Last reply Reply Quote 0
                          • 4 Offline
                            4NVXr3wHBnQYsHwE
                            last edited by

                            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

                            1 Reply Last reply Reply Quote 1
                            • stephenw10S Offline
                              stephenw10 Netgate Administrator
                              last edited by

                              It's a miracle! 😁

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.