WireGuard Archive on lore.kernel.org
 help / color / Atom feed
From: Vincent Wiemann <vincent.wiemann@ironai.com>
To: "Ivan Labáth" <labawi-wg@matrix-dream.net>,
	"Hendrik Friedel" <hendrik@friedels.name>
Cc: wireguard@lists.zx2c4.com
Subject: Re: Keep-alive does not keep the connection alive
Date: Wed, 11 Sep 2019 15:28:18 +0200
Message-ID: <33c80a5c-44f4-a20f-e3e3-7514a8f3d696@ironai.com> (raw)
In-Reply-To: <20190910091922.GA5679@matrix-dream.net>

Hello Ivan,

On 10.09.19 11:19, Ivan Labáth wrote:
> 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).
>>>>  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?
> For example, I don't want my server of my client continuously re-resolving DNS,
> for privacy reasons among others. Also I prefer kernel not mucking with
> DNS for security reasons>
>>> 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,
> which is currently minimal and such features are not (yet) implemented.
> Either way, the kernel should not handle DNS, the tooling where DNS
> handling belongs has no concept of reconnections, so the request is
> very far from a simple change and probably should not and even could
> not be done in the way you have described
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:

This would allow DynDNS scenarios without any monitoring daemons running
and proper configuration using systemd.

> Even in the kernel itself there is not a well defined concept connection,
> more like a peer state or session (ip, keys etc.) that is possibly valid
> or definitely invalid.
>>> 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.
>>>   - 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.
> 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)
> Regards,
> Ivan

WireGuard mailing list

      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             ` Re[2]: " Hendrik Friedel
2019-09-10  9:19               ` Ivan Labáth
2019-09-11 13:28                 ` Vincent Wiemann [this message]

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:

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

  git send-email \
    --in-reply-to=33c80a5c-44f4-a20f-e3e3-7514a8f3d696@ironai.com \
    --to=vincent.wiemann@ironai.com \
    --cc=hendrik@friedels.name \
    --cc=labawi-wg@matrix-dream.net \
    --cc=wireguard@lists.zx2c4.com \


* 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

Newsgroup available over NNTP:

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