that seems not to be the intended behaviour:
If I understand correctly, the current behaviour is:
At tunnel start the IP is resolved
This IP is used for ever, namingly for re-connects.
This is only partly correct. The remote endpoint can unconditionally
roam and is updated by any valid packet from a given IP (if I remember
correctly).
What does that mean?
Does that mean, that traffic will update the IP so that the problem will not appear?
The probably intended behaviour would be:
At tunnel start and at any re-connect the IP is resolved.
Do you agree that this behaviour should be changed?
Apart from that: Can you suggest an automatable workaround?
In some circumstances a similar behavior would be a desired.
That's ambigous.
In what circumstances, what behaviour would be desired?
Wireguard design and implementation is layered (which seems good).
The secure* tunnel, including the kernel module and wg tool seem
to be in a reasonable state, but automation, DNS, key exchange are
out of scope for them. It is meant to be provided by tooling, which is
currently very raw.
I don't understand...
When I am on my way in a roadwarrier scenario with my mobile, with a changing IP and a changing connection that works very well.
If the IP of my Server is changing, it's not working well at all. I don't think that this should be declared as 'works as intended'.
As a workaround you could
- unconditionally periodically update the endpoint