<html><head>
<style id="css_styles" type="text/css">blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; }
a img { border: 0px; }
li[style='text-align: center;'], li[style='text-align: right;'] { list-style-position: inside;}
body { font-family: Segoe UI; font-size: 12pt; }</style></head><body class="plain"><div>Hello,</div><div><br /></div><div>------ Originalnachricht ------</div>
<div>Von: "Ivan Labáth" <labawi-wg@matrix-dream.net></div>
<div>An: "Hendrik Friedel" <hendrik@friedels.name></div>
<div>Cc: "Laszlo KERTESZ" <laszlo.kertesz@gmail.com>; wireguard@lists.zx2c4.com</div>
<div>Gesendet: 10.09.2019 11:19:22</div>
<div>Betreff: Re: Keep-alive does not keep the connection alive</div><div><br /></div>
<div id="x85650cc1b3ab4be"><blockquote type="cite" class="cite2">
<div class="plain_line">On Sat, Sep 07, 2019 at 10:04:44AM +0000, Hendrik Friedel wrote:</div>
<blockquote type="cite" class="cite">
<div class="plain_line"> Hello,</div>
<div class="plain_line"> </div>
<div class="plain_line"> >> that seems not to be the intended behaviour:</div>
<div class="plain_line"> >> If I understand correctly, the current behaviour is:</div>
<div class="plain_line"> >></div>
<div class="plain_line"> >> At tunnel start the IP is resolved</div>
<div class="plain_line"> >> This IP is used for ever, namingly for re-connects.</div>
<div class="plain_line"> >This is only partly correct. The remote endpoint can unconditionally</div>
<div class="plain_line"> >roam and is updated by any valid packet from a given IP (if I remember</div>
<div class="plain_line"> >correctly).</div>
<div class="plain_line"> What does that mean?</div>
<div class="plain_line"> Does that mean, that traffic will update the IP so that the problem will</div>
<div class="plain_line"> not appear?</div>
</blockquote>
<div class="plain_line"> </div>
<div class="plain_line">If you have peers A and B with publicly rechable IP+port A1 and B1.</div>
<div class="plain_line">When A's ip+port changes from A1 to A2, then (assuming I remember correctly)</div>
<div class="plain_line">any properly authenticated traffic from A (now A2) to B (B1) will update</div>
<div class="plain_line">B's record of A's remote endpoint to A2. Any subsequent traffic from B will be</div>
<div class="plain_line">sent to A2.</div>
<div class="plain_line"> </div>
<div class="plain_line">Note, the roaming side (one with changed ip/port) must send the first</div>
<div class="plain_line">packet, so it should be the one sending keepalive messages and it is</div>
<div class="plain_line">the side where you should set the keepalive interval (for sending</div>
<div class="plain_line">packets).</div></blockquote><div id="x85650cc1b3ab4be">Yes, and that is a solution of 50% of the cases only.</div><div id="x85650cc1b3ab4be"><br /></div><div id="x85650cc1b3ab4be"><br /></div><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div>
<blockquote type="cite" class="cite2">
<div class="plain_line"> >Wireguard design and implementation is layered (which seems good).</div>
<div class="plain_line"> >The secure* tunnel, including the kernel module and wg tool seem</div>
<div class="plain_line"> >to be in a reasonable state, but automation, DNS, key exchange are</div>
<div class="plain_line"> >out of scope for them. It is meant to be provided by tooling, which is</div>
<div class="plain_line"> >currently very raw.</div>
<div class="plain_line"> </div>
<div class="plain_line"> I don't understand...</div>
<div class="plain_line"> When I am on my way in a roadwarrier scenario with my mobile, with a</div>
<div class="plain_line"> changing IP and a changing connection that works very well.</div>
<div class="plain_line"> If the IP of my Server is changing, it's not working well at all. I</div>
<div class="plain_line"> don't think that this should be declared as 'works as intended'.</div>
</blockquote>
<div class="plain_line"> </div>
<div class="plain_line">I am not saying wireguard solution is working as intended. I am saying</div>
<div class="plain_line">the DNS resolution is meant to be implemented in out-of-kernel tooling,</div></blockquote><div id="x85650cc1b3ab4be"><<It's a bit OT, but I actually think letting the kernel part of WireGuard</div><div id="x85650cc1b3ab4be">do the DNS queries is totally legit and a wishful (maybe optional) feature:</div><div id="x85650cc1b3ab4be">https://www.kernel.org/doc/Documentation/networking/dns_resolver.txt</div><div id="x85650cc1b3ab4be"> </div><div id="x85650cc1b3ab4be">This would allow DynDNS scenarios without any monitoring daemons running</div><div id="x85650cc1b3ab4be">and proper configuration using systemd.>> [Vincent Wiemann]]</div><div id="x85650cc1b3ab4be"><br /></div><br /><blockquote type="cite" class="cite2"><blockquote type="cite" class="cite2"><div class="plain_line"><br /> >As a workaround you could</div>
<div class="plain_line"> > - unconditionally periodically update the endpoint</div>
<div class="plain_line"> This would break existing transfers without reason.</div>
</blockquote>
<div class="plain_line"> </div>
<div class="plain_line">As I said, you could try periodically updating the endpoint, and only</div>
<div class="plain_line">endpoint, not restarting or changing anything except peer ip+port.</div>
<div class="plain_line">If updating endpoint information (to the same or valid ip+port) does break</div>
<div class="plain_line">connections, then I believe it is a bug that should be reported.</div></blockquote><div id="x85650cc1b3ab4be"><br /></div><div id="x85650cc1b3ab4be">I was not able to find commands for updating the endpoint without restarting the tunnel.</div><div id="x85650cc1b3ab4be">Can you give me a hint?</div><br /><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div>
<div class="plain_line"> </div>
<blockquote type="cite" class="cite2">
<div class="plain_line"> > - monitor last handshake time, when large update endpoint or restart</div>
<div class="plain_line"> > tunnel</div>
<div class="plain_line"> That could be an option.</div>
<div class="plain_line"> > - add keepalive to server - it might reduce your downtime</div>
<div class="plain_line"> How would that help?</div>
</blockquote>
<div class="plain_line"> </div>
<div class="plain_line">Keepalive is one-sided. As your client doesn't know where to send</div>
<div class="plain_line">the keepalive request, it doesn't help. Keepalive on the server can.</div></blockquote>I have activated keepalive on both client and server.</div><div id="x85650cc1b3ab4be"><br /></div><div id="x85650cc1b3ab4be"><br /><blockquote type="cite" class="cite2"><div class="plain_line">If the server changes IPs and the client remains reachable on previous ip+port,</div>
<div class="plain_line">keepalive on server should keep your tunnel alive.</div>
<div class="plain_line"> </div>
<div class="plain_line"> </div>
<div class="plain_line">Roaming will work if the side that changes ips:</div>
<div class="plain_line"> a) has keepalive enabled, so it will send a packet periodically</div>
<div class="plain_line"> b) sends an unsolicited packet (e.g. requests something from the</div>
<div class="plain_line"> other side as clients usually do but server less so)</div>
<div class="plain_line"> c) ip is changed after a request is received and before a reply is</div>
<div class="plain_line"> sent (could happen but unreliable)</div>
<div class="plain_line"><br /></div></blockquote><div id="x85650cc1b3ab4be"><br /></div><div id="x85650cc1b3ab4be">I think, there is an 'or' between a, b and c?</div><div id="x85650cc1b3ab4be"><br /></div><div id="x85650cc1b3ab4be">Greetings,</div><div id="x85650cc1b3ab4be">Hendrik</div><div id="x85650cc1b3ab4be"><br /></div><div id="x85650cc1b3ab4be"><br /></div><br /><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div>
</blockquote></div>
</body></html>