WireGuard Archive on lore.kernel.org
 help / color / Atom feed
From: "Hendrik Friedel" <hendrik@friedels.name>
To: "Ivan Labáth" <labawi-wg@matrix-dream.net>
Cc: wireguard@lists.zx2c4.com
Subject: Re[2]: Keep-alive does not keep the connection alive
Date: Thu, 17 Oct 2019 19:03:40 +0000
Message-ID: <emb3ce60aa-e0fe-4ef1-9955-18b08ac83546@ryzen> (raw)
In-Reply-To: <20190910091922.GA5679@matrix-dream.net>

[-- Attachment #1.1: Type: text/plain, Size: 4250 bytes --]

Hello,

------ Originalnachricht ------
Von: "Ivan Labáth" <labawi-wg@matrix-dream.net>
An: "Hendrik Friedel" <hendrik@friedels.name>
Cc: "Laszlo KERTESZ" <laszlo.kertesz@gmail.com>; 
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,
<<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.


>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



>

[-- Attachment #1.2: Type: text/html, Size: 8332 bytes --]

<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" &lt;labawi-wg@matrix-dream.net&gt;</div>
<div>An: "Hendrik Friedel" &lt;hendrik@friedels.name&gt;</div>
<div>Cc: "Laszlo KERTESZ" &lt;laszlo.kertesz@gmail.com&gt;; 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"> &gt;&gt;  that seems not to be the intended behaviour:</div>
<div class="plain_line"> &gt;&gt;  If I understand correctly, the current behaviour is:</div>
<div class="plain_line"> &gt;&gt;</div>
<div class="plain_line"> &gt;&gt;  At tunnel start the IP is resolved</div>
<div class="plain_line"> &gt;&gt;  This IP is used for ever, namingly for re-connects.</div>
<div class="plain_line"> &gt;This is only partly correct. The remote endpoint can unconditionally</div>
<div class="plain_line"> &gt;roam and is updated by any valid packet from a given IP (if I remember</div>
<div class="plain_line"> &gt;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"> &gt;Wireguard design and implementation is layered (which seems good).</div>
<div class="plain_line"> &gt;The secure* tunnel, including the kernel module and wg tool seem</div>
<div class="plain_line"> &gt;to be in a reasonable state, but automation, DNS, key exchange are</div>
<div class="plain_line"> &gt;out of scope for them. It is meant to be provided by tooling, which is</div>
<div class="plain_line"> &gt;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">&lt;&lt;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.&gt;&gt; [Vincent Wiemann]]</div><div id="x85650cc1b3ab4be"><br /></div><br /><blockquote type="cite" class="cite2"><blockquote type="cite" class="cite2"><div class="plain_line"><br /> &gt;As a workaround you could</div>
<div class="plain_line"> &gt;   - 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"> &gt;   - monitor last handshake time, when large update endpoint or restart</div>
<div class="plain_line"> &gt;     tunnel</div>
<div class="plain_line"> That could be an option.</div>
<div class="plain_line"> &gt;   - 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>

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

  parent reply index

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-21 19:13 Hendrik Friedel
     [not found] ` <CANH_QeYQ7hyBG1qK9PJB9E77gggW0NYe70vv8m6Dn=fU5zHQbg@mail.gmail.com>
2019-08-25 18:44   ` Re[2]: " Hendrik Friedel
2019-08-26 18:02     ` Ivan Labáth
2019-08-28  6:06       ` Re[2]: " Hendrik Friedel
2019-08-28  6:17       ` Laszlo KERTESZ
2019-08-28  6:25         ` Re[2]: " Hendrik Friedel
2019-08-28  6:37           ` Laszlo KERTESZ
2019-08-28  6:54           ` Ivan Labáth
2019-08-28  7:43             ` Laszlo KERTESZ
2019-09-07 10:04             ` Re[2]: " Hendrik Friedel
2019-09-10  9:19               ` Ivan Labáth
2019-09-11 13:28                 ` Vincent Wiemann
2019-10-17 19:03                 ` Hendrik Friedel [this message]
2019-10-20 20:25                   ` Ivan Labáth

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=emb3ce60aa-e0fe-4ef1-9955-18b08ac83546@ryzen \
    --to=hendrik@friedels.name \
    --cc=labawi-wg@matrix-dream.net \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

WireGuard Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ https://lore.kernel.org/wireguard \
		wireguard@lists.zx2c4.com
	public-inbox-index wireguard

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.zx2c4.lists.wireguard


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git