Well, NAT does work (= is able to change source of tunnel's packets), but not exactly as expected.
I can force tunnel to use link-local address as source, if I keep default route (with link-local gateway) and disable all global addresses. I assume something like that might be happening on your router, if you have dynamic config. Perhaps for a brief moment when it's renewed, there's route but not global address and tunnel has no choice and has to switch to link-local source. When global address becomes available again, sometimes tunnel switches to it right away and sometimes it takes a while (half a minute or so).
And then there's NAT. The rule sees packets. In fact, it sees every single one (so it understands them as new "connections"), but doesn't do anything as long as there's original connection tracking entry with public addresses. Only when it times out (after 10 minutes) or I remove it manually, it kicks in and works as it should, i.e. changes link-local source to configured public address (and it creates new connection tracking entry with link-local source, as expected). Trouble is, when this new connection tracking entry exists, then even if public address became available and tunnel uses it as source (I'm logging packets in output), it somehow blocks the tunnel, no packets are sent from router. But then again, 10 minutes, the entry expires and everything is fine again.
It's not exactly same as your problem, but something weird is definitely happening there.
I can force tunnel to use link-local address as source, if I keep default route (with link-local gateway) and disable all global addresses. I assume something like that might be happening on your router, if you have dynamic config. Perhaps for a brief moment when it's renewed, there's route but not global address and tunnel has no choice and has to switch to link-local source. When global address becomes available again, sometimes tunnel switches to it right away and sometimes it takes a while (half a minute or so).
And then there's NAT. The rule sees packets. In fact, it sees every single one (so it understands them as new "connections"), but doesn't do anything as long as there's original connection tracking entry with public addresses. Only when it times out (after 10 minutes) or I remove it manually, it kicks in and works as it should, i.e. changes link-local source to configured public address (and it creates new connection tracking entry with link-local source, as expected). Trouble is, when this new connection tracking entry exists, then even if public address became available and tunnel uses it as source (I'm logging packets in output), it somehow blocks the tunnel, no packets are sent from router. But then again, 10 minutes, the entry expires and everything is fine again.
It's not exactly same as your problem, but something weird is definitely happening there.
Statistics: Posted by Sob — Sun Dec 31, 2023 4:27 pm