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

    pfSense stops routing IPv6 after a few days

    Scheduled Pinned Locked Moved IPv6
    26 Posts 4 Posters 3.3k Views
    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.
    • I
      ijeff
      last edited by

      Thanks for the pointers. I do recall receiving 'no route to host' when I was attempting to ping an IPv6 address from a LAN device, hence my original assumption about it being pfSense.

      I will wait for IPv6 to drop again (probably will take 3-8 days before it will happen again) and perform the captures.

      I am assuming that selecting Interface WAN & Protocol ICMPv6 would be sufficient to get the data I'm looking for here?

      M 1 Reply Last reply Reply Quote 0
      • M
        msmith100 @ijeff
        last edited by

        @ijeff I'm not sure if not route to host means anything or not. Hopefully someone more knowledgeable than me can comment.

        You may want to capture more than ICMP - I'm thinking DHCPv6 queries at minimum. Might be best to capture everything but TCP for instance.

        That said, if you're not downloading anything there is not much harm in running a full capture for a few minutes.

        1 Reply Last reply Reply Quote 0
        • I
          ijeff
          last edited by ijeff

          Interestingly, it dropped again today. I've dropped the results below in a format which I hope is easy to read.

          Looks like you were right @msmith100, the pings are going out on the WAN interface but the ISP is not sending anything back in return. I guess pfSense is doing its job.

          If I contact the ISP's first level support, all I will get is questions as to why I'm not using their prescribed modem, so I'm not going to even bother. I know someone who works for the ISP but I'm not sure if they will know anyone in the technical departments who would be responsible for this.

          If there is any other advice I'll be happy to take it, but am I right to understand that pfSense is doing its job here and the ISP is the one dropping the ball?

          Is there another setting I can use? Is there another way to distribute IPv6 addresses on my LAN which can get things working? I wouldn't mind only having local addresses on my LAN (those fe80:: ones) if pfSense was able to route out with them, so if that is a quick and dirty option to have IPv6 internet then I would be keen on trying that, but may need to be pointed in the right direction.

          Any additional advice is appreciated.

          Pinging from LAN

          • Language-PING
          • Language-CAPTURE
          PING6(56=40+8+8 bytes) 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy --> 2620:119:35::35
          
          --- 2620:119:35::35 ping6 statistics ---
          10 packets transmitted, 0 packets received, 100.0% packet loss
          
          16:53:48.188300 IP6 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy > 2620:119:35::35: ICMP6, echo request, seq 0, length 16
          16:53:49.206391 IP6 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy > 2620:119:35::35: ICMP6, echo request, seq 1, length 16
          16:53:50.236773 IP6 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy > 2620:119:35::35: ICMP6, echo request, seq 2, length 16
          16:53:51.298848 IP6 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy > 2620:119:35::35: ICMP6, echo request, seq 3, length 16
          16:53:52.315938 IP6 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy > 2620:119:35::35: ICMP6, echo request, seq 4, length 16
          16:53:53.343213 IP6 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy > 2620:119:35::35: ICMP6, echo request, seq 5, length 16
          16:53:54.392126 IP6 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy > 2620:119:35::35: ICMP6, echo request, seq 6, length 16
          16:53:55.430711 IP6 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy > 2620:119:35::35: ICMP6, echo request, seq 7, length 16
          <

          Pinging from WAN

          • Language-PING
          • Language-CAPTURE
          PING6(56=40+8+8 bytes) 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx --> 2620:119:35::35
          16 bytes from 2620:119:35::35, icmp_seq=0 hlim=59 time=3.953 ms
          16 bytes from 2620:119:35::35, icmp_seq=1 hlim=59 time=3.586 ms
          16 bytes from 2620:119:35::35, icmp_seq=2 hlim=59 time=3.729 ms
          16 bytes from 2620:119:35::35, icmp_seq=3 hlim=59 time=3.901 ms
          16 bytes from 2620:119:35::35, icmp_seq=4 hlim=59 time=3.411 ms
          16 bytes from 2620:119:35::35, icmp_seq=5 hlim=59 time=3.690 ms
          16 bytes from 2620:119:35::35, icmp_seq=6 hlim=59 time=3.920 ms
          16 bytes from 2620:119:35::35, icmp_seq=7 hlim=59 time=3.070 ms
          16 bytes from 2620:119:35::35, icmp_seq=8 hlim=59 time=3.741 ms
          16 bytes from 2620:119:35::35, icmp_seq=9 hlim=59 time=3.423 ms
          
          --- 2620:119:35::35 ping6 statistics ---
          10 packets transmitted, 10 packets received, 0.0% packet loss
          round-trip min/avg/max/std-dev = 3.070/3.642/3.953/0.263 ms
          
          16:55:03.237296 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 0, length 16
          16:55:03.241141 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 0, length 16
          16:55:04.254633 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 1, length 16
          16:55:04.258155 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 1, length 16
          16:55:05.281568 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 2, length 16
          16:55:05.285203 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 2, length 16
          16:55:06.345437 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 3, length 16
          16:55:06.349222 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 3, length 16
          16:55:07.408905 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 4, length 16
          16:55:07.412162 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 4, length 16
          16:55:08.445631 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 5, length 16
          16:55:08.449137 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 5, length 16
          16:55:09.456343 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 6, length 16
          16:55:09.460179 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 6, length 16
          16:55:10.508092 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 7, length 16
          16:55:10.511094 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 7, length 16
          16:55:11.545480 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 8, length 16
          16:55:11.549159 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 8, length 16
          16:55:12.617936 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 9, length 16
          16:55:12.621150 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 9, length 16
          <
          1 Reply Last reply Reply Quote 0
          • M
            msmith100
            last edited by

            • My understanding is that if the packets are going out and nothing is coming back, then yes it's the ISP's problem, as long as they are correct - i.e. the source IP is in fact one of yours on the LAN, and hasn't mysteriously been mangled or set to some bad value in some way.
            • If your WAN has a /64, I don't think you can distribute that to LAN clients. I might be wrong though
            • Best solution might be doing IPv6 NAT with private addresses to the WAN or a He.net tunnel
            1 Reply Last reply Reply Quote 0
            • I
              ijeff
              last edited by

              My WAN is definitely /56, and the /64 was assigned by RA to the LAN, so I think that part is fine.

              I’m leaning towards IPv6 NAT, but will need to do some reading up on that.

              M 1 Reply Last reply Reply Quote 0
              • M
                msmith100 @ijeff
                last edited by

                @ijeff Your WAN is /56? That's extremely unusual.
                All the ISPs I've heard of either follow RFC 8415 (mine) or something close to it - a /64 for the WAN, /56 for the LAN and other networks behind the router.

                JKnottJ 1 Reply Last reply Reply Quote 0
                • JKnottJ
                  JKnott @msmith100
                  last edited by JKnott

                  @msmith100 said in pfSense stops routing IPv6 after a few days:

                  a /64 for the WAN, /56 for the LAN and other networks behind the router.

                  ????

                  I think you have that reversed. The LAN side is always /64 and the WAN is whatever the ISP provides.

                  PfSense running on Qotom mini PC
                  i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                  UniFi AC-Lite access point

                  I haven't lost my mind. It's around here...somewhere...

                  M 1 Reply Last reply Reply Quote 0
                  • I
                    ijeff
                    last edited by

                    It’s definitely /56 for WAN and /64 for LAN. I’ve confirmed this on the ISP issued router.

                    1 Reply Last reply Reply Quote 0
                    • ?
                      A Former User
                      last edited by A Former User

                      This post is deleted!
                      1 Reply Last reply Reply Quote 0
                      • M
                        msmith100 @JKnott
                        last edited by

                        @jknott Oops I think I should have been more clear. I mean a /64 for the WAN, and a /56 delegated to 1+ LAN networks, each of which is assigned 1 of 256 /64's from that /56 by pfsense per your configuration.
                        My current config, masked for privacy:

                         WAN (wan)       -> pppoe0     -> v4/PPPoE: 104.163.xxx.xxx/32
                                                          v6/DHCP6: 2606:6d00:1234:1234:1234:1234:1234:1234/64
                         LAN (lan)       -> bge0       -> v4: 192.168.0.100/24
                                                          v6: 2606:6d00:8888:1111::1/64
                        .....
                         VLAN4(opt4)   -> bge0.3     -> v4: 192.168.11.100/24
                                                          v6: 2606:6d00:8888:1112::1/64
                        

                        As I understand it, I could even not have a globally routable address on the WAN, and it would have no effect. I've seen some other people setup pfsense in that manner, actually - I think on Teksavvy?

                        @ijeff As long as your config matches what the ISP provides, then there should be no issue and it's their problem. I have heard of cases on various forums though of some ISPs with really strange configs (e.g. Telus on the west coast), including requiring non-standard (i.e. modifying config files manually) behavior w.r.t. DHCP renewing and such. That might be the case in your situation - pfsense is following standard RFCs, and your ISP is not. Further complicating manners, there are also some ISP-grade routers out there with known issues that had to be patched to fix weird IPv6 behavior in the last few years.

                        Wish I could help further...

                        JKnottJ 1 Reply Last reply Reply Quote 0
                        • I
                          ijeff
                          last edited by ijeff

                          So would it in theory be possible to use fe80:: addresses on the LAN side and have the router use NAT to pass everything through the single IPv6 address?

                          JKnottJ 1 Reply Last reply Reply Quote 0
                          • JKnottJ
                            JKnott @msmith100
                            last edited by

                            @msmith100 said in pfSense stops routing IPv6 after a few days:

                            As I understand it, I could even not have a globally routable address on the WAN, and it would have no effect. I've seen some other people setup pfsense in that manner, actually - I think on Teksavvy?

                            Quite possibly your WAN address is not used for routing. Check your default route with the netstat -r command. Don't be surprised if you see a link local address.

                            PfSense running on Qotom mini PC
                            i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                            UniFi AC-Lite access point

                            I haven't lost my mind. It's around here...somewhere...

                            M 1 Reply Last reply Reply Quote 0
                            • JKnottJ
                              JKnott @ijeff
                              last edited by

                              @ijeff

                              Why on earth would you want to do that? NAT was created to get around the IPv4 address shortage. On IPv6, a single /64 contains 18.4 billion, billion addresses.

                              PfSense running on Qotom mini PC
                              i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                              UniFi AC-Lite access point

                              I haven't lost my mind. It's around here...somewhere...

                              I 1 Reply Last reply Reply Quote 0
                              • I
                                ijeff @JKnott
                                last edited by

                                @jknott

                                Seemed like a quick and dirty way of getting IPv6 if my ISP has a non-compliant setup? If it’s not the way to do it then that’s fine.

                                Someone elsewhere has mentioned that I should investigate enabling large ICMP and ICMP v6 since that’s not allowed on the WAN side of the firewall, but I’m not on site at the moment.

                                JKnottJ 1 Reply Last reply Reply Quote 0
                                • JKnottJ
                                  JKnott @ijeff
                                  last edited by

                                  @ijeff

                                  What do you mean by "large ICMP"? That would tend to indicate an attack.

                                  PfSense running on Qotom mini PC
                                  i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                                  UniFi AC-Lite access point

                                  I haven't lost my mind. It's around here...somewhere...

                                  I 1 Reply Last reply Reply Quote 0
                                  • I
                                    ijeff @JKnott
                                    last edited by

                                    @jknott

                                    They specifically mentioned to make sure the following was enabled:

                                    • Allowing large ICMP
                                    • Allowing v6 ICMP across the network
                                    M 1 Reply Last reply Reply Quote 0
                                    • M
                                      msmith100 @JKnott
                                      last edited by

                                      @jknott No it's not. Still useful to have for pfsense itself as a pseudo-privacy layer e.g. for DNS requests, and I assume there is at least some good if non-essential reason it's part of an RFC and done by default by my ISP.

                                      1 Reply Last reply Reply Quote 0
                                      • M
                                        msmith100 @ijeff
                                        last edited by

                                        @ijeff I have no idea how that would help you. AFAIK by default pfsense has rules that allow the bare minimum essential IPv6 ICMP traffic, so that shouldn't be the cause of your issue.

                                        I 1 Reply Last reply Reply Quote 0
                                        • I
                                          ijeff @msmith100
                                          last edited by

                                          @msmith100

                                          I think you're right, it looks like pfSense is doing everything it needs to by default.

                                          I've been referred to this bug which seems to explain the exact issue I'm having. My ISP and the ISP mentioned in the bug actually use very similar network hardware (Cisco Nexus) so it may be completely related to that...

                                          I might wait until 2.5.0 is released with this bug fixed before trying further troubleshooting...

                                          1 Reply Last reply Reply Quote 0
                                          • I
                                            ijeff
                                            last edited by

                                            I've upgraded to 2.5.0 today and will monitor and report back.

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