Today my remote replication failed.
I use on the remote side a firewall rule that goes like this:
Allow all incoming form static IPv6_TrueNAS to static IPv6_TrueNAS_remote.
Worked fine for months. Now all of a sudden it fails. Strange. So I take a look at the firwall and see, TrueNAS is not using it’s in the webGUI statically applied IPv6, but some I guess privacy extension IPv6?
yeah that second global addr is an autoconf address from the kernel, not from your static GUI entry. SCALE still lets the interface pick up a SLAAC addr even when you typed a static IPv6, so outbound uses the wrong source and your remote firewall drops it.
check:
sysctl net.ipv6.conf.vlan51.use_tempaddr
sysctl net.ipv6.conf.vlan51.accept_ra
ip -6 route get <remote_ipv6>
to kill the extra addr for now:
sysctl -w net.ipv6.conf.vlan51.use_tempaddr=0
sysctl -w net.ipv6.conf.vlan51.accept_ra=0
ip -6 addr del 2000:2000:2000:51:527c:6fff:fe62:39c3/64 dev vlan51
make those stick under System → Tunables (or a post-up script). after that ip -6 addr show vlan51 should only show ::13 plus link-local, then re-run the replication.
I don’t get the current network philosophy of TrueNAS.
IMHO either you say:
we are a conservative server os. No tempaddr by default, no SLAAC or at least not if a static IPv6 is defined
we use the normal SLAAC and tempaddr, but then we also support “normal” networking like anybody else. By normal I for example mean that multiple interfaces can have DHCP enabled
thinkering with tunables is not really what I wanna do just to get basic networking settings.