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

    WAN and LAN IPv6

    Scheduled Pinned Locked Moved IPv6
    36 Posts 2 Posters 7.4k 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.
    • P
      pvexed
      last edited by

      Just looking at what my ISP said again, or at least part of it:

      Just need to configure static route at WAN device for AAAA:XXXX:1:ZZZ::/64 pointing towards your LAN

      Could there be anything to do that given I see when I packet cap on the WAN I see this:
      22:13:02.749090 IP6 fe80::V6_GATEWAY > LAN_CLIENT_V6: ICMP6, destination unreachable, unreachable address LAN_CLIENT_V6, length 112

      Which seems to be my ISP's gateway (at least its link-local) saying that it can't reach the addresses on my LAN?

      1 Reply Last reply Reply Quote 0
      • P
        pvexed
        last edited by

        I made some further progress but it's still not 100%.

        I noticed that in Diagnostics -> Routes, that AAAA:XXXX:1:ZZZ::/64 was being given a route on the same link as AAAA:XXXX:1:YYY::/64 even when I didn't have ZZZ defined in my LAN or anything.  This made me think that maybe my ISP's DHCP was adding this route which was perhaps confusing pfSense.

        So instead I turned off IPv6 on the WAN, and deleted the gateway for IPv6.  Then I made a new gateway with the ISP link-local address and with the IPv6 over IPv4 link checkbox checked.  Then I statically assigned the old IPv6 address my WAN had to the WAN and set that as the gateway.  WAN came back up and didn't look any different than before (pings/traceroutes from pfSense to internet working as expected).

        I checked Diagnostics -> Routes and I can see there's no route for ZZZ block, as expected.  So then I added ZZZ block to LAN as before, and still with upstream gateway set to none, so essentially exactly the same config.  After checking Diagnostics -> Routes now I can see ZZZ block has a route via the LAN port and not the PPPoE link.

        Fundamentally, IPv6 now works on LAN clients, I can go to https://ipv6.google.com without issue on LAN clients.  But something is still broken.  All pings and traceroutes stop at the pfSense box.  For example:
        tracert -6 google.com

        Tracing route to google.com [2a00:1450:4009:812::200e]
        over a maximum of 30 hops:

        1    <1 ms    <1 ms    <1 ms  pfsense.lan.xxxxx [AAAA:XXXX:1:ZZZ::1]

        Trace complete.

        1 Reply Last reply Reply Quote 0
        • ?
          Guest
          last edited by

          This begins to sound like my system. I have a PPPoE connection the negotiates on V4, then V6 is routed via the PPPoE link, my addresses are all static, although I can use dhcp6.

          When you say you cannot ping the LAN client, are you trying to ping it from the WAN?

          1 Reply Last reply Reply Quote 0
          • P
            pvexed
            last edited by

            So now on the LAN client I can ping the IPv6 LAN static IP (ZZZ block).  But also if I try to ping any other IPv6 address, it just terminates at that address (the IP statically assigned to the LAN).

            Here's some examples from a LAN client:

            ping -6 AAAA:XXXX:1:ZZZ::1
            
            Pinging 2a01:5d00:1:6ed::1 with 32 bytes of data:
            Reply from AAAA:XXXX:1:ZZZ::1: time<1ms
            Reply from AAAA:XXXX:1:ZZZ::1: time<1ms
            Reply from AAAA:XXXX:1:ZZZ::1: time<1ms
            Reply from AAAA:XXXX:1:ZZZ::1: time<1ms
            
            Ping statistics for AAAA:XXXX:1:ZZZ::1:
                Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
            Approximate round trip times in milli-seconds:
                Minimum = 0ms, Maximum = 0ms, Average = 0ms
            

            So far so good.

            ping -6 google.com
            
            Pinging google.com [2a00:1450:4009:812::200e] with 32 bytes of data:
            Reply from 2a00:1450:4009:812::200e: time<1ms
            Reply from 2a00:1450:4009:812::200e: time<1ms
            Reply from 2a00:1450:4009:812::200e: time<1ms
            Reply from 2a00:1450:4009:812::200e: time<1ms
            
            Ping statistics for 2a00:1450:4009:812::200e:
                Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
            Approximate round trip times in milli-seconds:
                Minimum = 0ms, Maximum = 0ms, Average = 0ms
            

            Doesn't look right, the ping to my ISP's gateway is about 7ms.  On traceroute we see:

            tracert -6 google.com
            
            Tracing route to google.com [2a00:1450:4009:812::200e]
            over a maximum of 30 hops:
            
              1    <1 ms    <1 ms    <1 ms  pfsense.lan.xxxxx [AAAA:XXXX:1:ZZZ::1]
            
            Trace complete.
            

            This obviously isn't correct and it seems like very strange behaviour.  Everything destined to somewhere not inside AAAA:XXXX:1:ZZZ::/64 seems to "terminate" at pfSense, and yet the LAN clients can use IPv6 only websites and connect to services on the public internet over IPv6.

            From the outside, trying to traceroute one of the LAN IPv6 addresses from the public internet, I see that the last hop before it's unable to continue is my WAN IPv6 (not my LAN).

            From inside the LAN, trying to connect or ping another LAN client over IPv6 works as I'd expect - it's direct and through the switch with no communication with pfSense.

            To answer your question - if I try to ping a LAN client from Diagnostics -> Ping with source address set to WAN, this appears to work.

            1 Reply Last reply Reply Quote 0
            • ?
              Guest
              last edited by

              When pinging from the outside in, you'll need to have a rule set up to allow that. All inbound traffic is blocked by default, apart from that which is of course in response to an outbound request.

              1 Reply Last reply Reply Quote 0
              • P
                pvexed
                last edited by

                @marjohn56:

                When pinging from the outside in, you'll need to have a rule set up to allow that. All inbound traffic is blocked by default, apart from that which is of course in response to an outbound request.

                Sorry, of course I've been messing with this IPv6 specific stuff for so long now I forget the easy stuff. Rule added on WAN to allow ICMP echorep/rechoreq when destination = LAN net has solved traceroute/ping from the outside.  So now the only remaining issue is traceroute/ping from the inside which is really weird.

                1 Reply Last reply Reply Quote 0
                • ?
                  Guest
                  last edited by

                  Try this ping this address and see what you get.

                  2001:41c1:4008::bbc:1

                  1 Reply Last reply Reply Quote 0
                  • P
                    pvexed
                    last edited by

                    @marjohn56:

                    Try this ping this address and see what you get.

                    2001:41c1:4008::bbc:1

                    Same thing, ping reports <1ms and tracert shows it stopping at my static LAN IP, 1 hop only.

                    A traceroute from Diagnotics -> Traceroute on pfSense with source address set as LAN works correctly, with the first hop being my ISP's fe80 link-local gateway.  So it's only traffic from actual LAN clients which seems to be affected.

                    1 Reply Last reply Reply Quote 0
                    • ?
                      Guest
                      last edited by

                      OK, got you, I misunderstood, I thought your LAN clients were pinging OK.

                      Right we are making progress. So you have a default pass out rule for the LAN, it should have been automatically created for you. LAN Net to Any, is  that there?

                      1 Reply Last reply Reply Quote 0
                      • P
                        pvexed
                        last edited by

                        @marjohn56:

                        OK, got you, I misunderstood, I thought your LAN clients were pinging OK.

                        Right we are making progress. So you have a default pass out rule for the LAN, it should have been automatically created for you. LAN Net to Any, is  that there?

                        Yes it's there, and been doing some more testing my end - this issue might be client specific.

                        On Linux, it's not an issue at all, traceroute and ping both work normally, including traceroute using ICMP.

                        On Windows, tracert and ping are not working as expected (but this could be down to other software on the machine).

                        On Android, I am using PingTools Pro.  In ICMP mode, traceroute works as expected, in UDP mode it doesn't seem to work properly.  Pings do work as expected though.

                        1 Reply Last reply Reply Quote 0
                        • P
                          pvexed
                          last edited by

                          Yeah it seems like the 1ms ping thing is a Kaspersky issue.  It was difficult to find but I found some references to others experiencing the issue and it's a bug in their network filtering driver.  So perhaps this issue is solved then.

                          https://forum.kaspersky.com/index.php?/topic/374028-kes-10-sp2-icmpv6-issue/&

                          1 Reply Last reply Reply Quote 0
                          • ?
                            Guest
                            last edited by

                            :) Yes, well - Kaspersky… Hmm

                            Not allowed near any of my machines.

                            Apart from the fact they may or may not be in leagues with the Kremlin I have always found it slows my machines down.

                            I use Webroot, never have an issue.

                            1 Reply Last reply Reply Quote 0
                            • P
                              pvexed
                              last edited by

                              @marjohn56:

                              :) Yes, well - Kaspersky… Hmm

                              Not allowed near any of my machines.

                              Apart from the fact they may or may not be in leagues with the Kremlin I have always found it slows my machines down.

                              I use Webroot, never have an issue.

                              Well either way, thanks for your help man - wouldn't have been able to do it without you.  I think the issue is pretty much sorted now.

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