Source address selection breaks router IPv6 connectivity when Tayga is enabled

[hugo]

I've got Tayga installed for NAT64. I noticed that, after Tayga was installed and activated, actions where the opnsense router itself was reaching out to the public Internet (router-originated traffic, not client / transit traffic) was broken. A key example was that package/firmware updates and plugin searches and such were broken. I eventually tracked this down to IPv6 traffic specifically.

With more digging, this turned out to be that the router would select the "IPv6 NAT64 Interface Address" address from Tayga configuration as the source IPv6 address for outgoing traffic. This probably makes some sense, as in my case this I was using something in the doc prefix, as 2001:db8:1:ffff::1. That ends up being the lowest numbered GUA address on system, which is a common enough criteria for source address selection algorithms.

That IPv6 address obviously is not actually bound on the system and isn't Internet-routable, so traffic would leave the box with that source address and never make it back.

Adding a NAT policy for just that "IPv6 NAT64 Interface Address" works, in selecting another local IP address as the NAT target address, but it definitely was a confusing symptom.

Can we perhaps add something into the Tayga docs at https://docs.opnsense.org/manual/how-tos/tayga.html that maybe this should be a ULA or something? Since I'm getting IPv6 addressing via DHCPv6-PD, it's not feasible for me to enter a fixed GUA address in here, for instance. My fix for now has been to dedicated the last /64 out of my /48 ULA range as the "IPv6 NAT64 Interface Address", so that it should not be eligible as a source IP address for talking to GUA resources on the public Internet.

Alternatively, I'm not sure if there is a way to "exclude" the Tayga address from being eligible in source address selection?