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 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
                                        • I
                                          ijeff
                                          last edited by

                                          No further issues since upgrading to 2.5.0. Looks like the bugs have been squashed!

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