Hello, ------ Originalnachricht ------ Von: "Ivan Labáth" An: "Hendrik Friedel" Cc: "Laszlo KERTESZ" ; wireguard@lists.zx2c4.com Gesendet: 10.09.2019 11:19:22 Betreff: Re: Keep-alive does not keep the connection alive >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, <> [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. >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) > I think, there is an 'or' between a, b and c? Greetings, Hendrik >