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

Yes, and that is a solution of 50% of the cases only.

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

<<It's a bit OT, but I actually think letting the kernel part of WireGuard

do the DNS queries is totally legit and a wishful (maybe optional) feature:

https://www.kernel.org/doc/Documentation/networking/dns_resolver.txt

This would allow DynDNS scenarios without any monitoring daemons running

and proper configuration using systemd.>> [Vincent Wiemann]]

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

I was not able to find commands for updating the endpoint without restarting the tunnel.

Can you give me a hint?

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

I have activated keepalive on both client and server.