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: Sat, 07 Sep 2019 10:04:44 +0000
Message-ID: <emc2cb759b-1a2b-4bd0-a4f8-77ed32053cff@ryzen> (raw)
In-Reply-To: <20190828065411.GA6914@matrix-dream.net>

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

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

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

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

>
>As a workaround you could
>   - unconditionally periodically update the endpoint
This would break existing transfers without reason.
>   - 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?

Greetings,
Hendrik


>




>

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

<html><head><style>#x93406428d40e43d5be476ffb5412c83f #x70fb53580d9c415c9d6c4afe5251441b{
	font-family:'Segoe UI';
	font-size:12pt;
}
#x93406428d40e43d5be476ffb5412c83f{
	font-family:'Segoe UI';
	font-size:12pt;
}#x70fb53580d9c415c9d6c4afe5251441b
{font-family: 'Segoe UI'; font-size: 12pt;}
</style>

<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 id="x1378faaa1981473"><blockquote type="cite" class="cite2"><blockquote type="cite" class="cite"><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>
</blockquote>
<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></blockquote><div id="x1378faaa1981473">What does that mean?</div><div id="x1378faaa1981473">Does that mean, that traffic will update the IP so that the problem will not appear?</div><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div></blockquote><br /><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div>
<blockquote type="cite" class="cite2">
<div class="plain_line"> The probably intended behaviour would be:</div>
<div class="plain_line"> At tunnel start and at any re-connect the IP is resolved.</div>
<div class="plain_line"> </div>
<div class="plain_line"> Do you agree that this behaviour should be changed?</div>
<div class="plain_line"> Apart from that: Can you suggest an automatable workaround?</div>
</blockquote>
<div class="plain_line"> </div>
<div class="plain_line">In some circumstances a similar behavior would be a desired.</div></blockquote><div id="x1378faaa1981473"><br /></div><div id="x1378faaa1981473">That's ambigous.</div><div id="x1378faaa1981473">In what circumstances, what behaviour would be desired?</div><div id="x1378faaa1981473"><br /></div><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div>
<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></blockquote><div id="x1378faaa1981473"><br /></div><div id="x1378faaa1981473">I don't understand... </div><div id="x1378faaa1981473">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.</div><div id="x1378faaa1981473">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'.</div><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div></blockquote><br /><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div>
<div class="plain_line">As a workaround you could</div>
<div class="plain_line">  - unconditionally periodically update the endpoint</div></blockquote></div><div id="x1378faaa1981473"><div id="x93406428d40e43d5be476ffb5412c83f"><div class="plain"><div id="x1378faaa1981473"><div id="x70fb53580d9c415c9d6c4afe5251441b"><div class="plain"><div id="x1378faaa1981473">This would break existing transfers without reason.</div></div></div></div></div></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></blockquote>That could be an option.<br /><blockquote type="cite" class="cite2"><div class="plain_line">  - add keepalive to server - it might reduce your downtime</div></blockquote>How would that help?</div><div id="x1378faaa1981473"><br /></div><div id="x1378faaa1981473">Greetings,</div><div id="x1378faaa1981473">Hendrik</div><div id="x1378faaa1981473"><br /></div><div id="x1378faaa1981473"><br /><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div></blockquote><div id="x1378faaa1981473"><br /></div><div id="x1378faaa1981473"></div><div id="x1378faaa1981473"><br /></div><div id="x1378faaa1981473"><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: 12+ 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             ` Hendrik Friedel [this message]
2019-09-10  9:19               ` Ivan Labáth
2019-09-11 13:28                 ` Vincent Wiemann

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=emc2cb759b-1a2b-4bd0-a4f8-77ed32053cff@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 zx2c4-wireguard@archiver.kernel.org
	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