router loses IPv6, error in routing logs

lifespeed

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

JKnott

@lifespeed

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

JKnott

@lifespeed

PfSense runs on FreeBSD, not Linux.

lifespeed

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

@lifespeed

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.

JKnott

@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.

JKnott

@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

@JKnott

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

lifespeed

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

@JKnott

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.

JKnott

@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.

evberd

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.

lifespeed

@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.