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

    Global WAN Address disappears

    IPv6
    4
    12
    5.0k
    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.
    • D
      darkcrucible
      last edited by

      I've been using PFSense with Comcast since June 1st and it has been working great with IPv6. I've been using it with the DHCP6-PD configuration. The WAN interface gets an address, let us just say 2001:xxx::yyy/128 and is delegated 2601:xxx::/64. All the clients on the LAN get something in the 2601:xxx::/64 range, as expected.

      I noticed that after 11 days (this time), the 2001:xxx::yyy/128 address disappears. It no longer shows on the interface status page nor does it show on the main webgui page. Just so I'm clear, this has no effect on connectivity for any LAN clients or the PFsense box itself. After all, the PFSene box still has it's addresses from the 2601:xxx::/64 range on the LAN interface that it assigned itself and the default gateway always seem to use link-local (FE80) addresses.

      I was just wondering if this is expected? The last time this happened, I rebooted and got the /128 address back. If this wasn't supposed to happen, my PFSense box is currently in this state, so I might be able to help with tracking down what happened.

      One last thing, I'm using a 2.1 development snapshot from June 1st. NanoBSD

      1 Reply Last reply Reply Quote 0
      • W
        whfsdude
        last edited by

        This is not at all expected. That /64 PD should be routed to your point to point address ( /128 the WAN DHCPv6) so I'm not sure how exactly inbound routing is working.

        Have you popped open a shell and looked to see if the address is still bound to the interface? Maybe it's just not showing in the WebUI.

        1 Reply Last reply Reply Quote 0
        • johnpozJ
          johnpoz LAYER 8 Global Moderator
          last edited by

          This is kind of related to the question I had about using link local as the gateway address in my thread where I can not get comcast default route at all in my pfsense.

          @whfsdude – you stated in that thread using link local was fine.  But if your going to use link-local what is the point of the global address for the connection??

          If not going to use that global address to talk to comcast with, but the link local - what do I need it for?

          Which seems to be what is happening here.  I would assume since that address is via dhcpv6, that it did not renew and the lease expired is why its missing from the gui

          But sure as suggested, I would check to see if still on the interface with a ifconfig command.

          An intelligent man is sometimes forced to be drunk to spend time with his fools
          If you get confused: Listen to the Music Play
          Please don't Chat/PM me for help, unless mod related
          SG-4860 24.11 | Lab VMs 2.7.2, 24.11

          1 Reply Last reply Reply Quote 0
          • W
            whfsdude
            last edited by

            @johnpoz:

            But if your going to use link-local what is the point of the global address for the connection??

            Because your PD prefix might not be on-net. So lets assume you're delegated a /56. You might want to have routers beyond your single router that would work automatically. (Eg. users daisy chain APs). In this case, they wouldn't be able to communicate directly with Comcast's LL gateway. At least that's my assumption why it was set up this way.

            So basically your router PD prefix might not appear on-net for Comcast which is why they have to route to an on-net address (on-net being your WAN point to point).

            on-net == being on the layer 2 segment doing ND.

            If not going to use that global address to talk to Comcast with, but the link local - what do I need it for?

            The reason they push a scope local gateway is just because it makes sense to do so. If they pushed a unicast global, it would need to look up the scope local and use NDP anyway. Because you're also specifying the interface used, I suspect doing it this way will be a lot better when doing multi-wan in v6 without BGP.

            1 Reply Last reply Reply Quote 0
            • D
              darkcrucible
              last edited by

              I ran ifconfig and it only shows the link local address for the WAN. The 2001:xxx::yyy address is not there. The LAN shows the 2601:xxx::1 address and the LL address. They both show the correct IPv4 configuration too. There is also no entry in the routing table for the 2001 address.

              As an aside, I think requesting the /128 is optional. I think there is a flag in DHCP6 that requests one. The IA-NA flag. I'm having trouble confirming that because searches keep trying to show my things about IANA which is not what I want. sigh

              1 Reply Last reply Reply Quote 0
              • D
                databeestje
                last edited by

                I didn't mention it before, but Router Advertisments always send a link-local address of the gateway, sure it may have a global address, but that's for traceroute. Link-local is always for directly reachable nodes.

                So yes, link-local addresses are normal. On that note, it could be that the dhcp6 client exited, and took the WAN address with it, which is weird, because it appears to have left the Prefix Delegation address on the LAN.

                Check if the dhcp6c process is still there, the logging on it is a bit brief though. Maybe it exited on lease renewal.

                1 Reply Last reply Reply Quote 0
                • D
                  darkcrucible
                  last edited by

                  I don't see dhcp6c running from ps auxwww output. Here is all of the lines that have dhcp in it:

                  root     170  0.0  0.8  4976  1896  ??  Is    8Jun12   0:08.28 /usr/sbin/syslogd -c -c -l /var/dhcpd/var/run/log -f /var/etc/syslog.conf
dhcpd   9447  0.0  2.0  8448  4768  ??  SNs   9:15AM   0:00.49 /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid vr0
dhcpd  12068  0.0  1.3  7424  3212  ??  SNs   9:15AM   0:00.59 /usr/local/sbin/dhcpd -6 -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid vr0
_dhcp  36403  0.0  0.6  3388  1376  ??  INs  Wed02AM   0:00.46 dhclient: vr1 (dhclient)

                  The system logs seemed to relate to the IPv4 DHCP stuff.

                  1 Reply Last reply Reply Quote 0
                  • D
                    databeestje
                    last edited by

                    It appears the dhcp6c client has exited for a reason, can you see those in the system logs? Should be there.

                    1 Reply Last reply Reply Quote 0
                    • D
                      darkcrucible
                      last edited by

                      ok oops. The log apparently had a lot of info about dhcp6. Luckily I saved an old copy. The current one has been overwritten with new events from today. Here is the old which I think includes the closing of the dhcp6 client:

                      Jun 18 09:39:20         apinger: alarm canceled: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 09:39:20         apinger: alarm canceled: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 09:40:19         apinger: ALARM: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 09:40:23         apinger: ALARM: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 09:41:31         apinger: alarm canceled: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 09:41:31         apinger: alarm canceled: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 09:42:03         apinger: ALARM: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 09:42:03         apinger: ALARM: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 09:43:26         apinger: alarm canceled: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 09:43:26         apinger: alarm canceled: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 09:43:51         apinger: ALARM: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 09:43:51         apinger: ALARM: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 09:46:35         apinger: alarm canceled: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 09:46:35         apinger: alarm canceled: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 09:48:55         apinger: ALARM: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 09:48:55         apinger: ALARM: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 09:50:06         apinger: alarm canceled: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 09:50:06         apinger: alarm canceled: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 09:50:51         apinger: ALARM: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 09:50:51         apinger: ALARM: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 09:51:18         apinger: alarm canceled: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 09:51:18         apinger: alarm canceled: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 09:56:02         apinger: ALARM: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 09:56:02         apinger: ALARM: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 09:57:13         apinger: alarm canceled: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 09:57:13         apinger: alarm canceled: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 09:57:34         apinger: ALARM: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 09:57:35         apinger: ALARM: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 09:58:52         apinger: alarm canceled: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 09:58:52         apinger: alarm canceled: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 10:01:14         apinger: ALARM: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 10:01:14         apinger: ALARM: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 10:02:26         apinger: alarm canceled: WAN_DHCP(24.6.100.1) *** delay ***
Jun 18 10:02:27         apinger: alarm canceled: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** delay ***
Jun 18 21:32:20         apinger: Exiting on signal 15.
Jun 18 21:32:21         apinger: Starting Alarm Pinger, apinger(35033)
Jun 18 21:32:21         apinger: bind socket: Can't assign requested address
Jun 18 21:32:32         apinger: Exiting on signal 15.
Jun 18 21:32:33         apinger: Starting Alarm Pinger, apinger(38172)
Jun 18 21:32:33         apinger: bind socket: Can't assign requested address
Jun 20 02:02:35         apinger: ALARM: WAN_DHCP(24.6.100.1) *** down ***
Jun 20 02:02:35         apinger: ALARM: WAN_DHCP6(fe80::201:5cff:fe31:b7c1) *** down ***
Jun 20 02:03:44         apinger: Exiting on signal 15.
Jun 20 02:03:45         apinger: Starting Alarm Pinger, apinger(37917)
Jun 20 02:03:45         apinger: No usable targets found, exiting
Jun 20 02:05:12         apinger: Starting Alarm Pinger, apinger(16284)
Jun 20 19:59:19         apinger: ALARM: WAN_DHCP(24.6.100.1) *** delay ***
Jun 20 20:00:50         apinger: alarm canceled: WAN_DHCP(24.6.100.1) *** delay ***
Jun 21 09:00:07         apinger: ALARM: WAN_DHCP(24.6.100.1) *** delay ***
Jun 21 09:10:39         apinger: alarm canceled: WAN_DHCP(24.6.100.1) *** delay ***

                      Not really sure what's going on though. This is from the webgui via system logs for DHCP.
                      edit: Sorry, this is actually from the webgui Status: System logs: Gateways

                      1 Reply Last reply Reply Quote 0
                      • D
                        darkcrucible
                        last edited by

                        Here is the Status: System logs: DHCP. If there's another log I should post, let me know. I'm not really sure what else there is.

                        Jun 22 09:06:38 	dhcpd: All rights reserved.
Jun 22 09:06:38 	dhcpd: For info, please visit https://www.isc.org/software/dhcp/
Jun 22 09:06:38 	dhcpd: Wrote 0 deleted host decls to leases file.
Jun 22 09:06:38 	dhcpd: Wrote 0 new dynamic host decls to leases file.
Jun 22 09:06:38 	dhcpd: Wrote 4 leases to leases file.
Jun 22 09:06:38 	dhcpd: Listening on BPF/vr0/00:0d:b9:1c:4a:d0/192.168.112.0/24
Jun 22 09:06:38 	dhcpd: Sending on BPF/vr0/00:0d:b9:1c:4a:d0/192.168.112.0/24
Jun 22 09:06:38 	dhcpd: Sending on Socket/fallback/fallback-net
Jun 22 09:15:21 	dhcpd: Internet Systems Consortium DHCP Server 4.2.3
Jun 22 09:15:21 	dhcpd: Copyright 2004-2011 Internet Systems Consortium.
Jun 22 09:15:21 	dhcpd: All rights reserved.
Jun 22 09:15:21 	dhcpd: For info, please visit https://www.isc.org/software/dhcp/
Jun 22 09:15:21 	dhcpd: Internet Systems Consortium DHCP Server 4.2.3
Jun 22 09:15:21 	dhcpd: Copyright 2004-2011 Internet Systems Consortium.
Jun 22 09:15:21 	dhcpd: All rights reserved.
Jun 22 09:15:21 	dhcpd: For info, please visit https://www.isc.org/software/dhcp/
Jun 22 09:15:21 	dhcpd: Wrote 0 deleted host decls to leases file.
Jun 22 09:15:21 	dhcpd: Wrote 0 new dynamic host decls to leases file.
Jun 22 09:15:21 	dhcpd: Wrote 4 leases to leases file.
Jun 22 09:15:21 	dhcpd: Listening on BPF/vr0/00:0d:b9:1c:4a:d0/192.168.112.0/24
Jun 22 09:15:21 	dhcpd: Sending on BPF/vr0/00:0d:b9:1c:4a:d0/192.168.112.0/24
Jun 22 09:15:21 	dhcpd: Sending on Socket/fallback/fallback-net
Jun 22 09:15:22 	dhcpd: Internet Systems Consortium DHCP Server 4.2.3
Jun 22 09:15:22 	dhcpd: Copyright 2004-2011 Internet Systems Consortium.
Jun 22 09:15:22 	dhcpd: All rights reserved.
Jun 22 09:15:23 	dhcpd: For info, please visit https://www.isc.org/software/dhcp/
Jun 22 09:15:23 	dhcpd: Internet Systems Consortium DHCP Server 4.2.3
Jun 22 09:15:23 	dhcpd: Copyright 2004-2011 Internet Systems Consortium.
Jun 22 09:15:23 	dhcpd: All rights reserved.
Jun 22 09:15:23 	dhcpd: For info, please visit https://www.isc.org/software/dhcp/
Jun 22 09:15:23 	dhcpd: Wrote 0 leases to leases file.
Jun 22 09:15:23 	dhcpd: Bound to *:547
Jun 22 09:15:23 	dhcpd: Listening on Socket/10/vr0/2601:9:4d80:58::/64
Jun 22 09:15:23 	dhcpd: Sending on Socket/10/vr0/2601:9:4d80:58::/64
Jun 22 09:32:25 	dhcpd: DHCPREQUEST for 192.168.112.101 from 54:04:a6:37:1c:da via vr0
Jun 22 09:32:25 	dhcpd: DHCPACK on 192.168.112.101 to 54:04:a6:37:1c:da via vr0
Jun 22 09:58:51 	dhcpd: DHCPDISCOVER from 00:15:58:07:d8:b4 via vr0
Jun 22 09:58:51 	dhcpd: DHCPOFFER on 192.168.112.195 to 00:15:58:07:d8:b4 via vr0
Jun 22 09:58:51 	dhcpd: DHCPREQUEST for 192.168.112.195 (192.168.112.1) from 00:15:58:07:d8:b4 via vr0
Jun 22 09:58:51 	dhcpd: DHCPACK on 192.168.112.195 to 00:15:58:07:d8:b4 via vr0
Jun 22 10:21:54 	dhcpd: DHCPREQUEST for 192.168.112.101 from 54:04:a6:37:1c:da via vr0
Jun 22 10:21:54 	dhcpd: DHCPACK on 192.168.112.101 to 54:04:a6:37:1c:da via vr0
Jun 22 11:08:52 	dhcpd: DHCPREQUEST for 192.168.112.101 from 54:04:a6:37:1c:da via vr0
Jun 22 11:08:52 	dhcpd: DHCPACK on 192.168.112.101 to 54:04:a6:37:1c:da via vr0
Jun 22 13:03:34 	dhcpd: DHCPDISCOVER from 00:15:58:07:d8:b4 via vr0
Jun 22 13:03:34 	dhcpd: DHCPOFFER on 192.168.112.195 to 00:15:58:07:d8:b4 via vr0
Jun 22 13:03:34 	dhcpd: DHCPREQUEST for 192.168.112.195 (192.168.112.1) from 00:15:58:07:d8:b4 via vr0
Jun 22 13:03:34 	dhcpd: DHCPACK on 192.168.112.195 to 00:15:58:07:d8:b4 via vr0
Jun 22 13:06:30 	dhcpd: DHCPREQUEST for 192.168.112.101 from 54:04:a6:37:1c:da via vr0
Jun 22 13:06:30 	dhcpd: DHCPACK on 192.168.112.101 to 54:04:a6:37:1c:da via vr0
                        1 Reply Last reply Reply Quote 0
                        • D
                          databeestje
                          last edited by

                          there are no messages from dhcp6c which is the dhcp6 client in there. We'll have to try again.

                          1 Reply Last reply Reply Quote 0
                          • D
                            darkcrucible
                            last edited by

                            Now that I know what to look for, I might be able to catch whatever caused the problem next time it happens. I'll post here again if I can get this info.

                            I did notice a problem with connectivity today. Inbound connections were not being routed to hosts behind pfsense. The packets would arrive but pfsense would drop them. Outbound connections worked so it was like being under NAT. After I rebooted pfsense, all inbound connections worked and the /128 address of pfsense shows up in traceroutes. The /128 definitely seems needed for normal operation at least with my config with Comcast.

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