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 0645CC43331 for ; Sat, 7 Sep 2019 10:05:49 +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 3A28C20854 for ; Sat, 7 Sep 2019 10:05:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3A28C20854 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 81d534b3; Sat, 7 Sep 2019 10:04:50 +0000 (UTC) Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id a828ed15 for ; Sat, 7 Sep 2019 10:04:48 +0000 (UTC) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.110]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id cf178de5 for ; Sat, 7 Sep 2019 10:04:48 +0000 (UTC) Received: from [84.61.93.104] (helo=[192.168.177.20]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from ) id 1i6XaI-0006yf-Sb; Sat, 07 Sep 2019 12:04:46 +0200 From: "Hendrik Friedel" To: =?utf-8?q?Ivan=20Lab=c3=a1th?= Subject: Re[2]: Keep-alive does not keep the connection alive Date: Sat, 07 Sep 2019 10:04:44 +0000 Message-Id: In-Reply-To: <20190828065411.GA6914@matrix-dream.net> References: <20190826180244.GB5022@matrix-dream.net> <20190828065411.GA6914@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="===============4292451733509165423==" Errors-To: wireguard-bounces@lists.zx2c4.com Sender: "WireGuard" --===============4292451733509165423== Content-Type: multipart/alternative; boundary="------=_MB39AD2061-877A-4181-AEDB-EEA144F0F9FF" --------=_MB39AD2061-877A-4181-AEDB-EEA144F0F9FF Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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=20 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=20 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=20 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 > > --------=_MB39AD2061-877A-4181-AEDB-EEA144F0F9FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello,

=
that seems not to be the intended beha= viour:
If I understand correctly, the current behaviour = is:
=C2=A0
At tunnel start the IP is resolved
This IP is used for ever, namingly for re-connec= ts.
This is only partly correct. The remote endpoint= can unconditionally
roam and is updated by any valid packet from a gi= ven 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?<= /div>


The probably intended behaviour would be:
At tunnel start and at any re-connect the IP is= resolved.
=C2=A0
Do you agree that this behaviour should be chang= ed?
Apart from that: Can you suggest an automatable= workaround?
=C2=A0
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 (w= hich seems good).
The secure* tunnel, including the kernel module a= nd 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 understa= nd...
When I am on my way in a roadwarri= er scenario with my mobile, with a changing IP and a changing connection th= at works very well.
If the IP of my Serve= r 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 endpo= int
This would break existing transfers without reason.=
- monitor last handshake time, when large up= date endpoint or restart
tunnel
That could be an opt= ion.
- add keepalive to server - it might reduce your downtime
How would that help?

Greetings,
Hen= drik








--------=_MB39AD2061-877A-4181-AEDB-EEA144F0F9FF-- --===============4292451733509165423== 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 --===============4292451733509165423==--