pfSense IPv6 prefix change blues.

I recently changed my ISP and it came with the ability to actually use IPv6. It wasn’t the sole reason for the switch, but it was a happy bonus which came with the deal. This means I’ve finally gotten the opportunity to play with configuring it on my gateway device and internally to my network. It’s been an adventure.

The change of ISPs also came with a static IPv4 address–but unfortunately this didn’t come with a static v6 prefix. This has caused some problems in how my networks are segregated (and the ability to alias against prefixes seems a fairly common feature request). It’s also resulted in me discovering a bug in how pfSense handles changes in prefix.

The cause.

Like most Canadian internet customers, my uplink (regardless of ISP) has never been as stable as might be hoped. It’s not a daily outage or anything, but I can usually expect a connection reset once every couple weeks at least. (I think much of the time it may actually be a scheduled system restart for the company providing the infrastructure.). It’s fine–I don’t pay for a high availability commercial line or anything–and my gateway’s IPv4 connection restores perfectly. But oh boy, the IPv6 connection does not.

Because it’s not a static IPv6 prefix, after every reconnect I end up with a new prefix. This prefix is then propagated to all my hosts. Perfect! As intended. …but for some reason, only hosts on the same physical segment can talk to each other over v6. No external communication. No communication to other segments.

The good news is, it’s obviously an issue with my gateway. The bad news is it has taken me forever to figure out exactly what the issue is.

The problem.

After a bit of research each time it’s happened, it looks like losing IPv6 services on a prefix change is pretty common. But the majority of bug reports I’ve found are long closed and resolved. Following the directions from those bug reports and ‘resetting’ the WAN interface (by a save+apply) brings everything back up after a few minutes. As does restarting the router. That doesn’t explain what the problem is though. The fact that the new prefix propagates to downstream hosts is also confusing, but indicative that the problem is somehow related to firewall filtering. A review of the firewall logs seems to confirm that.

The problem is, for my LAN, I don’t have any role to block or filter traffic.

So what gives? I only noticed it by accident, but when I used the hover feature on the LAN subnets alias it was only showing an IPv4 address. Well, there’s the problem.

Okay, but why.

So, there are some firewall aliases which are automatically generated by pfSense. They’re easy enough to see under Firewall / Aliases / All. Or so I thought.

Well, the system generated aliases for the various interfaces will not show up in this list at all. It will show up in the rules debug file located at /tmp/rules.debug (this is the first time I learned that file exists). So, what appears to happen is when a prefix change occurs, the alias for the interface subnet isn’t updated in the rules file.

So we have the answer.

Now what?

Similar to all the other bug reports I’ve seen on pfSense when an IPv6 prefix changes, all you need to do is “reset” the interface by applying no change to it. Annoying, but an easy fix and the aliases are all refreshed and come up after a few minutes.

I suppose alternatively if there was a way to restart the firewall it would probably rebuild the rules at that point. So pick your poison (but I haven’t tested the latter myself).

I’m still digging through pfSense bug reports, and haven’t generated a new one. Next time it happens though (so, about two weeks), I’ll take screen captures and generate a report. If I do, I’ll try to remember to add the number to the end of this post.