Keep-alive does not keep the connection alive

[Ivan Labáth]

On Sat, Sep 07, 2019 at 10:04:44AM +0000, Hendrik Friedel wrote:
> 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?

If you have peers A and B with publicly rechable IP+port A1 and B1.
When A's ip+port changes from A1 to A2, then (assuming I remember correctly)
any properly authenticated traffic from A (now A2) to B (B1) will update
B's record of A's remote endpoint to A2. Any subsequent traffic from B will be
sent to A2.

Note, the roaming side (one with changed ip/port) must send the first
packet, so it should be the one sending keepalive messages and it is
the side where you should set the keepalive interval (for sending
packets).

> 
> >
> >>  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?

For example, I don't want my server of my client continuously re-resolving DNS,
for privacy reasons among others. Also I prefer kernel not mucking with
DNS for security reasons.

> >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'.

I am not saying wireguard solution is working as intended. I am saying
the DNS resolution is meant to be implemented in out-of-kernel tooling,
which is currently minimal and such features are not (yet) implemented.
Either way, the kernel should not handle DNS, the tooling where DNS
handling belongs has no concept of reconnections, so the request is
very far from a simple change and probably should not and even could
not be done in the way you have described.

Even in the kernel itself there is not a well defined concept connection,
more like a peer state or session (ip, keys etc.) that is possibly valid
or definitely invalid.

> >As a workaround you could
> >   - unconditionally periodically update the endpoint
> This would break existing transfers without reason.

As I said, you could try periodically updating the endpoint, and only
endpoint, not restarting or changing anything except peer ip+port.
If updating endpoint information (to the same or valid ip+port) does break
connections, then I believe it is a bug that should be reported.

> >   - 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?

Keepalive is one-sided. As your client doesn't know where to send
the keepalive request, it doesn't help. Keepalive on the server can.
If the server changes IPs and the client remains reachable on previous ip+port,
keepalive on server should keep your tunnel alive.


Roaming will work if the side that changes ips:
  a) has keepalive enabled, so it will send a packet periodically
  b) sends an unsolicited packet (e.g. requests something from the
     other side as clients usually do but server less so)
  c) ip is changed after a request is received and before a reply is
     sent (could happen but unreliable)

Regards,
Ivan