From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1D49ECE58E for ; Thu, 17 Oct 2019 19:04:04 +0000 (UTC) Received: from krantz.zx2c4.com (krantz.zx2c4.com [192.95.5.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AEE262089C for ; Thu, 17 Oct 2019 19:04:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AEE262089C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=friedels.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=wireguard-bounces@lists.zx2c4.com Received: from krantz.zx2c4.com (localhost [IPv6:::1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id d94cace4; Thu, 17 Oct 2019 19:03:45 +0000 (UTC) Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id b17318c3 for ; Thu, 17 Oct 2019 19:03:43 +0000 (UTC) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.109]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id eab13596 for ; Thu, 17 Oct 2019 19:03:43 +0000 (UTC) Received: from [91.56.71.153] (helo=[192.168.177.20]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iLB3l-0001A4-3G; Thu, 17 Oct 2019 21:03:41 +0200 From: "Hendrik Friedel" To: =?utf-8?q?Ivan=20Lab=c3=a1th?= Subject: Re[2]: Keep-alive does not keep the connection alive Date: Thu, 17 Oct 2019 19:03:40 +0000 Message-Id: In-Reply-To: <20190910091922.GA5679@matrix-dream.net> References: <20190826180244.GB5022@matrix-dream.net> <20190828065411.GA6914@matrix-dream.net> <20190910091922.GA5679@matrix-dream.net> User-Agent: eM_Client/7.2.34062.0 Mime-Version: 1.0 X-Df-Sender: aGVuZHJpa0BmcmllZGVscy5uYW1l Cc: wireguard@lists.zx2c4.com X-BeenThere: wireguard@lists.zx2c4.com X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Hendrik Friedel List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2288687611260973297==" Errors-To: wireguard-bounces@lists.zx2c4.com Sender: "WireGuard" --===============2288687611260973297== Content-Type: multipart/alternative; boundary="------=_MB15FADCE5-A32D-4F3E-AA77-18CC9EF23FD7" --------=_MB15FADCE5-A32D-4F3E-AA77-18CC9EF23FD7 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, ------ Originalnachricht ------ Von: "Ivan Lab=C3=A1th" An: "Hendrik Friedel" Cc: "Laszlo KERTESZ" ;=20 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 wil= l >> 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 correctl= y) >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 wil= l 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=20 restarting the tunnel. Can you give me a hint? > > >> > - monitor last handshake time, when large update endpoint or restar= t >> > 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 > --------=_MB15FADCE5-A32D-4F3E-AA77-18CC9EF23FD7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello,

------ Originalnachricht = ------
Von: "Ivan Lab=C3=A1th" <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
<= br />
On Sat, Sep 07, 2019 at 10:04:44AM +0000, Hendrik = Friedel wrote:
Hello,
=C2=A0
>> that seems not to be the intended beha= viour:
>> 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 endp= oint 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?
=C2=A0
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 (ass= uming 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 subs= equent traffic from B will be
sent to A2.
=C2=A0
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 inter= val (for sending
packets).
Yes, and that is a solution of 50% of the cases only.


=

<= /div>
>Wireguard design and implementation is layer= ed (which seems good).
>The secure* tunnel, including the kernel mod= ule 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 pro= vided by tooling, which is
>currently very raw.
=C2=A0
I don't understand...
When I am on my way in a roadwarrier scenario wi= th 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 wor= king well at all. I
don't think that this should be declared as 'wor= ks as intended'.
=C2=A0
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,
<&= lt;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 Wi= emann]]



>As a workaround you could
> - unconditionally periodically update the = endpoint
This would break existing transfers without reas= on.
=C2=A0
As I said, you could try periodically updating th= e endpoint, and only
endpoint, not restarting or changing anything exc= ept 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 shou= ld be reported.

=
I was not able to find commands for updating t= he endpoint without restarting the tunnel.
Can you give me a hint?


=C2=A0
> - monitor last handshake time, when large = update endpoint or restart
> tunnel
That could be an option.
> - add keepalive to server - it might redu= ce your downtime
How would that help?
=C2=A0
Keepalive is one-sided. As your client doesn't kn= ow where to send
the keepalive request, it doesn't help. Keepalive = on the server can.
I have activated keepalive on both cl= ient and server.


If the server changes IPs and the client remains reachable= on previous ip+port,
keepalive on server should keep your tunnel alive= .
=C2=A0
=C2=A0
Roaming will work if the side that changes ips:
a) has keepalive enabled, so it will send a pac= ket periodically
b) sends an unsolicited packet (e.g. requests s= omething from the
other side as clients usually do but server= less so)
c) ip is changed after a request is received an= d before a reply is
sent (could happen but unreliable)


I think, there is an 'or' bet= ween a, b and c?

Greetings,
Hendrik
=




--------=_MB15FADCE5-A32D-4F3E-AA77-18CC9EF23FD7-- --===============2288687611260973297== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard --===============2288687611260973297==--