From: "Hendrik Friedel" <hendrik@friedels.name>
To: "Ivan Labáth" <labawi-wg@matrix-dream.net>
Cc: wireguard@lists.zx2c4.com
Subject: Re[2]: Keep-alive does not keep the connection alive
Date: Thu, 17 Oct 2019 19:03:40 +0000 [thread overview]
Message-ID: <emb3ce60aa-e0fe-4ef1-9955-18b08ac83546@ryzen> (raw)
In-Reply-To: <20190910091922.GA5679@matrix-dream.net>
[-- Attachment #1.1: Type: text/plain, Size: 4250 bytes --]
Hello,
------ Originalnachricht ------
Von: "Ivan Labáth" <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
>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).
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,
<<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 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
restarting the tunnel.
Can you give me a hint?
>
>
>> > - 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.
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
>
[-- Attachment #1.2: Type: text/html, Size: 8332 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
next prev parent reply other threads:[~2019-10-17 19:04 UTC|newest]
Thread overview: 14+ 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
2019-10-17 19:03 ` Hendrik Friedel [this message]
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=emb3ce60aa-e0fe-4ef1-9955-18b08ac83546@ryzen \
--to=hendrik@friedels.name \
--cc=labawi-wg@matrix-dream.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).