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
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
