router loses IPv6, error in routing logs

  • I have been running 2.4.4-RELEASE-p3 for about 6 months on a Supermicro X11SDV-4C-TP8F 4-core Xeon. It is behind a Netgear CM1000 cable modem on Xfinity with pfSense configured for prefix delegation /60 and DHCPv6. The 10Gb SFP+ LAN port is connected to a Ubiquiti US-16-XG switch. For the most part it has been very good.

    Unfortunately I have seen pfSense occasionally lose the IPv6 address from Comcast. This might happen after the router has been running for a week or two. I don't notice it immediately because IPv4 still works, I only see it when the server on the LAN pointed to by DNS becomes inaccessible from the WAN.

    In the routing logs, after a reboot I see:

    Even though I suspect a router problem, in order to get an IPv6 address I have to reboot both the router and the cable modem. Just rebooting the router won't work. In the past I think I have plugged a PC directly into the cable modem and received an IPv6 address (I'll double check next time this happens), so it isn't clear it is the fault of the cable modem.

    From this post I see this error may be related to IPv6, if it is any help figuring this out.

    Thanks in advance for any help. This is really hurting the reliability of my network, and I'm not quite sure how to track it down.

  • Here is an ArchLinux bug report about this issue, although I understand pfSense uses a different distribution of Linux.

  • @lifespeed

    Capture the DHCPv6-PD frames on the WAN interface and post them here.

  • @lifespeed

    PfSense runs on FreeBSD, not Linux.

  • @JKnott said in router loses IPv6, error in routing logs:


    Capture the DHCPv6-PD frames on the WAN interface and post them here.

    With the router connected, with a laptop, while the router doesn't have an IPv6? How would I mirror the port on my switch to capture when the switch isn't connected to the cable modem?

    You say this rather casually, yet even with modest networking knowledge I couldn't begin to guess how to do this.

    Here is a DHCP log entry indicating a problem:

    May 12 17:23:20 	dhcpd 		/etc/dhcpdv6.conf line 23: partial base64 value left over: 7.

  • @lifespeed

    Run Diagnostics > Packet Capture
    Configure for ICMP6 on WAN
    Disconnect/reconnect the WAN cable. This will trigger DHCPv6-PD.
    Then download the capture and post it here.
    You can also examine it with Wireshark.

  • @lifespeed

    BTW, a few years ago, I bought a cheap 5 port managed switch and configured it as a network tap, by using port mirroring. I can place that switch between my pfSense box and the cable modem. Works well.

  • @JKnott

    Correction, filter on dhcpv6, which is port 546 or 547.

  • @JKnott said in router loses IPv6, error in routing logs:


    Correction, filter on dhcpv6, which is port 546 or 547.

    I'lI give this a try tonight after work, although I'm not sure if there will be anything learned if the router currently has an IPv6. Guess we'll see.

    I still think there is a clue in the radvd.conf error logs posted previously.

  • @lifespeed

    If nothing else it will show what normal looks like. On the other hand, it could show a problem. Last year I had a problem with IPv6 from my ISP. By using packet capture, I was able to not only show there was a problem at my ISP, but even identify the failing system by name. Packet captures are an extremely useful tool in trying to resolve network problems.

    BTW, one thing I frequently do is fire up Wireshark, just to see how things work. This makes it much easier when trying to solve a problem, as I know what normal looks like.

  • Hello all. If you haven't found a resolution to this I believe I have stumbled onto what fixed this problem for me. I experienced this problem when I elected to change the prefix delegated IPv6 networks from Comcast from prefix delegation assigned to statically assigned. I didn't like the idea of the network address being dynamically assigned so I decided to take the delegated networks and define the host portion as ::1/64. This works fine until you have a disruption in service which could be a couple of hours or a couple of months. When a disruption in service does occur I have found that because I have statically set the gateways and there are no longer any LAN ports with a prefix ID configured on the netgate which in turn doesn't trigger the netgate request a /60 for prefix delegation. For whatever reason this also causes the WAN to not request the public IPv6 address. I have run many a packet capture to try and figure out why no request was being made but didn't find any particular reason for this. Additionally I have rebuilt my configuration and reinstalled the software multiple times. Each time IPv6 would work because initially I would allow prefix delegation to happen to find out what the /60 will be and then configure them statically on my LAN. (Note about my setup is that I have my LAN set as a trunk to a switch with multiple VLANs)

    How I have resolved this issue and kept the statically assigned gateways (Example 2001:600:8000::1/64 instead of 2001:600:8000:🔢abcd/64) was to create a new VLAN on my LAN interface that has the statically assigned gateways and assigned a prefix ID to it (You don't need to use VLANs if that doesn't work for your setup you just need a port that is up and configured with a prefix ID for prefix delegation). While this VLAN isn't used and has no hosts on it that doesn't matter. What matters is that there is an interface that is up and is configured to request prefix delegation. Once that happens it gets a /64 from the /60 and in turn triggers the WAN address to get an IPv6 address as needed for external connectivity. I can confirm this is stable and have rebooted the netgate multiple times and have suffered connectivity disruptions multiple times and haven't experienced a relapse in this behavior.

  • @evberd thanks for posting. I just lost connectivity again today, triggering the multiple-reboot cycle of pFsense until it would finally pull an IPv6 for my WAN and LAN. While I can grit my teeth and suffer through this until I get it going before the next disruption, it is truly vexing behavior. I woke up to no connectivity a few days ago due to Comcast equipment maintenance, and had to spend half an hour and was late to work because I needed to get the internet going for distance learning for my kids.

    That said, I've read what you've written a couple times, and it hasn't completely sunk in. I have tried using VLAN before and failed miserably. I am not an expert.

    I do use dynamic DNS as Comcast has changed my IP address several times over the past 6 months, I think due to equipment upgrades which is not a bad thing. The performance is impressive. Dynamic DNS does actually work, and does not seem to be a terrible solution for residential service.