WireGuard Archive on lore.kernel.org
 help / color / Atom feed
From: "Ivan Labáth" <labawi-wg@matrix-dream.net>
To: Hendrik Friedel <hendrik@friedels.name>
Cc: wireguard@lists.zx2c4.com
Subject: Re: Keep-alive does not keep the connection alive
Date: Tue, 10 Sep 2019 09:19:22 +0000
Message-ID: <20190910091922.GA5679@matrix-dream.net> (raw)
In-Reply-To: <emc2cb759b-1a2b-4bd0-a4f8-77ed32053cff@ryzen>

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.

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
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

  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 [this message]
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=20190910091922.GA5679@matrix-dream.net \
    --to=labawi-wg@matrix-dream.net \
    --cc=hendrik@friedels.name \
    --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


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