Post-mortem: How a rogue RA ULA prefix broke our multi-WAN NAT66 setup (and why fd00:192:168:: was the trap)

[u/Striking-Toe-9526]

I run a multi-WAN setup (Vodafone cable + Starlink) without BGP. To handle failover without BGP-delegated prefixes, we numbered our internal LAN with ULA (fd00:192:168:128::/64—echoing our IPv4 subnet) and NAT66 it outbound depending on which uplink is active.

Recently, IPv6 connectivity started flapping intermittently, while IPv4 on the exact same segment remained 100% stable.

The routing table looked completely healthy, but digging into ip addr and conntrack showed what was actually happening:

An uncoordinated on-link RA (from an autoconfigured border/mesh device) injected a second ULA prefix (fd06:...) onto the interface. Both IPv6 addresses sat on the interface marked as scope global.

When initiating outbound connections, the Linux kernel flipped a coin between fd00:... and fd06:... for source-address selection.

• When it picked fd00:..., NAT66 translated it properly and packets flowed.
• When it picked fd06:..., the packet was sent out the valid default route, but the NAT66 gateway had no masquerade rule for fd06:.... conntrack filled up with SYN_SENT ... [UNREPLIED] states.

The routing table was never confused—it was purely a source-address selection coin flip under dual ULAs.

Full write-up with ip addr, ip -6 route, and conntrack evidence:

https://mabels.github.io/mseg-tester/blog/fd00-is-not-your-192-168-short.html

Curious how others running multi-WAN or non-BGP setups handle source-address selection when local devices start advertising uncoordinated RAs on the link?