I’m working on a dual-WAN IPv6 setup in pfSense and I’ve hit a design limitation that I’d like to discuss and get feedback on.
Scenario
pfSense with two IPv6 WAN links
Each WAN provides a /48 prefix (PA, provider-assigned)
Internal network is segmented into multiple VLANs
Each VLAN is assigned one /64 per WAN, so hosts receive two global IPv6 addresses via SLAAC
Router Advertisements are configured per VLAN in Assisted mode
This part works as expected: hosts become multihomed and can reach the internet through either link.
The Problem
pfSense only allows setting Router Priority per interface (VLAN), not per advertised prefix.
That means:
All prefixes advertised on a given VLAN share the same RA parameters
There is no way to prefer one prefix over another at the RA level
Prefix-specific Preferred Lifetime or deprecation is not supported
As a result:
I can influence which router/gateway is preferred
But I cannot reliably control which IPv6 source address (prefix) hosts will choose
Source address selection is left to the client OS (RFC 6724), which can lead to:
Suboptimal path selection
Blackholing when one WAN fails
Delayed recovery for existing connections
What I’m Trying to Achieve
Prefer prefix A when WAN A is up
Automatically deprecate prefix A (Preferred Lifetime = 0) when WAN A goes down
Allow hosts to immediately favor prefix B without waiting on heuristics or timeouts
All of this without requiring host-side configuration
Questions for the Community
Has anyone implemented a clean solution for prefix prioritization in pfSense?
Are there known plans to support per-prefix RA control in pfSense (or underlying radvd)?
Has anyone successfully used:
Scripts tied to gateway status (dpinger) to dynamically reload RA?
NPTv6 as a pragmatic workaround in enterprise environments?
For those running production IPv6 dual-WAN:
Do you accept this limitation and rely on host behavior?
Or did you move to PI + BGP to solve this properly?
Current Conclusion
From what I can see, this is not a configuration mistake but a tooling limitation. pfSense handles basic IPv6 dual-WAN reasonably well, but lacks the granularity needed for deterministic prefix selection.
I’d appreciate any real-world experiences, design patterns, or confirmation that I’m not missing something obvious.
Yes the battle of the IPv6 prefix delegation by ISP. This is something I had to address over a year ago with a client that had both Comcast Business as primary and then AT&T as a backup. Both business plans give out static IP’s for addressing but those IP’s are not “portable” Thus they are nailed to each vendor.
And to make things worse IPv6 is more about trying to make it easy for client device to acquire and use an address and making the lives of administrators a nightmare and most devices hate it when you pull the rug out on one prefix and try to bring in a new prefix when the WAN/ISP fails over.
The only solution I have found is to move to a ULA addressing model for you VLAN’s and then masquerade / NAT out to the ISP’s. I successfully deployed this with Unifi UDM’s but never tried on pfSense.
Now that this solution has been working for about a year the client has moved to 80% of their network traffic goes into Comcast and 20% to AT&T using load balancing.
Thank you for the detailed reply, Ron, I really appreciate you sharing real-world experience.
Over the last two days of research and testing, my initial strategy was exactly what you described as the “natural” IPv6 approach:
Advertise both ISP prefixes via RA on each VLAN
Let endpoints become multihomed
Rely on RA updates (router lifetime / prefix deprecation) so pfSense would signal link failure to the hosts
Conceptually, I expected pfSense to be able to inform endpoints through RA when one WAN went offline, and for the clients to gracefully stop using the affected prefix.
Your response was the first time I saw the issue clearly stated from an operational standpoint: endpoints really don’t like it when prefixes change, even when that change is technically correct per RFCs. That aligns with what I’m seeing. The behavior is protocol-compliant but operationally fragile, especially with long-lived connections and client-side heuristics.
So at this point, I fully agree that this is less a configuration mistake and more a structural problem with PA IPv6 in multi-ISP environments.
Given the constraints:
Provider-assigned prefixes that are not portable
Lack of per-prefix prioritization in RA
Client OS behavior being outside of the administrator’s control
My last viable alternative is moving toward a ULA-based internal addressing model, keeping internal IPv6 stable and independent of the ISP, and then translating at the edge. I understand this effectively reintroduces NAT concepts into IPv6, but at least it restores predictability and operational sanity.
I haven’t implemented this yet on pfSense, but your experience confirms that this approach can actually work in production, even with load balancing across ISPs.
Thanks again for sharing your experience. It helped validate that this is a real-world IPv6 design challenge, not just a lab curiosity.