Hello,

>>  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
This would break existing transfers without reason.
>   - monitor last handshake time, when large update endpoint or restart
>     tunnel
That could be an option.
>   - add keepalive to server - it might reduce your downtime
How would that help?

Greetings,
Hendrik


>




>