Keep-alive does not keep the connection alive
hendrik at friedels.name
Sat Sep 7 12:04:44 CEST 2019
>> 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
What does that mean?
Does that mean, that traffic will update the IP so that the problem will
>> 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.
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
That could be an option.
> - add keepalive to server - it might reduce your downtime
How would that help?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the WireGuard