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: Wed, 28 Aug 2019 06:54:11 +0000 [thread overview]
Message-ID: <20190828065411.GA6914@matrix-dream.net> (raw)
In-Reply-To: <em05f3a9de-8e41-4353-affa-3fb52e65cda8@ryzen>
Hello,
I was asking about server ip in the live wg config
on the client, as seen in
# wg show
in order to verify the problem is indeed a stale ip.
On Wed, Aug 28, 2019 at 06:25:15AM +0000, Hendrik Friedel wrote:
> 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).
> 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.
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.
As a workaround you could
- unconditionally periodically update the endpoint
- monitor last handshake time, when large update endpoint or restart
tunnel
- add keepalive to server - it might reduce your downtime
Regards,
Ivan Labáth
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
next prev parent reply other threads:[~2019-08-28 6:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-21 19:13 Keep-alive does not keep the connection alive 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 [this message]
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
2019-10-17 19:03 ` Re[2]: " Hendrik Friedel
2019-10-20 20:25 ` Ivan Labáth
Reply instructions:
You may reply publicly 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=20190828065411.GA6914@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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.