markus.woschank at gmail.com
Fri Nov 17 23:06:11 CET 2017
> My example is most useful when both endpoints are roaming and either
> endpoint needs to be able to initiate sessions. It's not a very
> common scenario I'll give you that, but the current full roaming
> support does enable it seamlessly (when you also enable keep-alives).
Thank you for clarifying.
This really sound like an unusual situation, where you need to make
sure that while one peer is down the other doesn't move.
I wonder if this could not, should the need arise, be solved in another fashion.
>From experience I have another concern towards the current mechanism.
When configuring two peers pointing at each other and by mistake
setting one endpoint IP to a wrong value (typo in the IP) there is a
good chance this mistake may not be noticed for quiet some time, if
the correctly configured endpoint initiates the connection most of the
time. The user (me), believing to have correctly configured the link,
may be taken by surprise at a later point in time when the link is not
established, as he expects, when the wrongly configured side tries to
initiate it after say a reboot. This is more of a concern to me than
supporting to roaming peers.
Also the thought of something like `wg showconf wg0 >
/etc/wireguard/wg0.conf` happening at shutdown frightens me a little.
Because if the command fails for whatever reason the configuration
will be truncated and after the reboot completes the link will be
non-functional (conf vs state).
Please don't interpret my comments the wrong way, I grew to love
wireguard. Just trying to state the kinks (IMO) I see, and this is one
I still vote for: if an endpoint is specified, don't allow the peer
from another source - no config syntax change needed ;).
More information about the WireGuard