Keep-alive does not keep the connection alive

Keep-alive does not keep the connection alive

[Hendrik Friedel]

[-- Attachment #1.1: Type: text/plain, Size: 2736 bytes --]

Hello,

I have a setup in which the Server IP is known, whereas the Client IP is 
changing. Thus, I rely on the Client to connect to the Server. I want 
the Client to keep the connection alive all the time though, so that the 
Server can also initiate a connection to the Server when needed. Both, 
client and server are behind a NAT/Router.
I would think, that the "PersistentKeepalive = 25" on the Client would 
ckeep the connection open. The connection works fine while used. But 
after a while, I cannot connect from the Server to the client anymore.
I would assume that a ping from the Client to the IP of the endpoint 
would help to re-alive the connection - but it does not.

Only after a wg-quick down and up all is fine again.

Below some more information.

Can you help me to find, what I am doing wrong?

Regards,
Hendrik



At the time of the problem "wg" shows on the Client:
interface: wgnet0
   public key: cebXSxxx=
   private key: (hidden)
   listening port: 60147
   fwmark: 0xca6c

peer:  oNjoixxx=
   endpoint: 92.210.7.177:51820
   allowed ips: 0.0.0.0/0
   latest handshake: 1 day, 7 hours, 44 minutes, 19 seconds ago
   transfer: 48.48 GiB received, 1.22 TiB sent
   persistent keepalive: every 25 seconds


and on the Server
  wg
interface: wgnet0
   public key: oNjoijXxxx=
   private key: (hidden)
   listening port: 51820

peer: cebXSxx=
   endpoint: 185.22.142.254:60147
   allowed ips: 10.192.122.3/32
   latest handshake: 1 day, 7 hours, 46 minutes, 5 seconds ago
   transfer: 67.24 MiB received, 651.37 MiB sent

peer: ZiTlYnxx=
   endpoint: 109.41.65.27:5935
   allowed ips: 10.192.122.2/32
   latest handshake: 2 days, 21 hours, 49 minutes, 25 seconds ago
   transfer: 11.98 MiB received, 127.11 MiB sent


Note the "transfer" being different between the two by far. I show the 
peer "ZiTIY" for completeness only. I do not think that it is relevant.











The Client config:
[Interface]
Address = 10.192.122.3/32
PrivateKey = xx=

[Peer]
PublicKey = yy=
Endpoint = Dyn.IP:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

The Server config:
[Interface]
Address = 10.192.122.1/24
SaveConfig = true
PostUp = iptables -A FORWARD -i wgnet0 -j ACCEPT; iptables -A FORWARD -o 
wgnet0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wgnet0 -j ACCEPT; iptables -D FORWARD 
-o wgnet0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j 
MASQUERADE
ListenPort = 51820
PrivateKey = aa=

[Peer]
PublicKey = bb=
AllowedIPs = 10.192.122.2/32
Endpoint = hidden:41646

[Peer]
PublicKey = cc=
AllowedIPs = 10.192.122.3/32
Endpoint = hidden:60147





[-- Attachment #1.2: Type: text/html, Size: 4307 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re[2]: Keep-alive does not keep the connection alive

[Hendrik Friedel]

Hello,

thanks for your reply.
It is linux (Kernel 5.x) in both cases.

Regards,
Hendrik

------ Originalnachricht ------
Von: "Vasili Pupkin" <diggest@gmail.com>
An: "Hendrik Friedel" <hendrik@friedels.name>
Cc: wireguard@lists.zx2c4.com
Gesendet: 25.08.2019 17:59:59
Betreff: Re: Keep-alive does not keep the connection alive

>What OS is running on client side? I have this issue on Win7 client,
>can explain it further, it has nothing to do with keepalives though,
>it is a bug in tun adapter implementation
>
>On Sun, Aug 25, 2019 at 6:38 PM Hendrik Friedel <hendrik@friedels.name> wrote:
>>  I have a setup in which the Server IP is known, whereas the Client IP is changing. Thus, I rely on the Client to connect to the Server. I want the Client to keep the connection alive all the time though, so that the Server can also initiate a connection to the Server when needed. Both, client and server are behind a NAT/Router.
>>  I would think, that the "PersistentKeepalive = 25" on the Client would ckeep the connection open. The connection works fine while used. But after a while, I cannot connect from the Server to the client anymore.
>>  I would assume that a ping from the Client to the IP of the endpoint would help to re-alive the connection - but it does not.
>>
>>  Only after a wg-quick down and up all is fine again.
>>
>>  Below some more information.
>>
>>  Can you help me to find, what I am doing wrong?

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Keep-alive does not keep the connection alive

[Ivan Labáth]

Hello,

I notice you are using dynamic ips for server.
On the client, is the server peer ip correct?

Regards,
Ivan

On Sun, Aug 25, 2019 at 06:44:53PM +0000, Hendrik Friedel wrote:
> Hello,
> 
> thanks for your reply.
> It is linux (Kernel 5.x) in both cases.
> 
> Regards,
> Hendrik
> 
> ------ Originalnachricht ------
> Von: "Vasili Pupkin" <diggest@gmail.com>
> An: "Hendrik Friedel" <hendrik@friedels.name>
> Cc: wireguard@lists.zx2c4.com
> Gesendet: 25.08.2019 17:59:59
> Betreff: Re: Keep-alive does not keep the connection alive
> 
> >What OS is running on client side? I have this issue on Win7 client,
> >can explain it further, it has nothing to do with keepalives though,
> >it is a bug in tun adapter implementation
> >
> >On Sun, Aug 25, 2019 at 6:38 PM Hendrik Friedel <hendrik@friedels.name> wrote:
> >>  I have a setup in which the Server IP is known, whereas the Client IP is changing. Thus, I rely on the Client to connect to the Server. I want the Client to keep the connection alive all the time though, so that the Server can also initiate a connection to the Server when needed. Both, client and server are behind a NAT/Router.
> >>  I would think, that the "PersistentKeepalive = 25" on the Client would ckeep the connection open. The connection works fine while used. But after a while, I cannot connect from the Server to the client anymore.
> >>  I would assume that a ping from the Client to the IP of the endpoint would help to re-alive the connection - but it does not.
> >>
> >>  Only after a wg-quick down and up all is fine again.
> >>
> >>  Below some more information.
> >>
> >>  Can you help me to find, what I am doing wrong?
> 
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re[2]: Keep-alive does not keep the connection alive

[Hendrik Friedel]

[-- Attachment #1.1: Type: text/plain, Size: 2700 bytes --]

Hello,

yes, the Sever has a dynamic IP.

 >On the client, is the server peer ip correct?
Which entry are you refering to?
I assume
Endpoint = Dyn.IP:51820

Yes, but otherwise, the connection would not even be established, right?

For reference, here the complete client config:
[Interface]
Address = 10.192.122.3/32
PrivateKey = xx=

[Peer]
PublicKey = yy=
Endpoint = Dyn.IP:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Regards,
Hendrik



------ Originalnachricht ------
Von: "Ivan Labáth" <labawi-wg@matrix-dream.net>
An: "Hendrik Friedel" <hendrik@friedels.name>
Cc: "Vasili Pupkin" <diggest@gmail.com>; wireguard@lists.zx2c4.com
Gesendet: 26.08.2019 20:02:44
Betreff: Re: Keep-alive does not keep the connection alive

>Hello,
>
>I notice you are using dynamic ips for server.
>On the client, is the server peer ip correct?
>
>Regards,
>Ivan
>
>On Sun, Aug 25, 2019 at 06:44:53PM +0000, Hendrik Friedel wrote:
>>  Hello,
>>
>>  thanks for your reply.
>>  It is linux (Kernel 5.x) in both cases.
>>
>>  Regards,
>>  Hendrik
>>
>>  ------ Originalnachricht ------
>>  Von: "Vasili Pupkin" <diggest@gmail.com>
>>  An: "Hendrik Friedel" <hendrik@friedels.name>
>>  Cc: wireguard@lists.zx2c4.com
>>  Gesendet: 25.08.2019 17:59:59
>>  Betreff: Re: Keep-alive does not keep the connection alive
>>
>>  >What OS is running on client side? I have this issue on Win7 client,
>>  >can explain it further, it has nothing to do with keepalives though,
>>  >it is a bug in tun adapter implementation
>>  >
>>  >On Sun, Aug 25, 2019 at 6:38 PM Hendrik Friedel <hendrik@friedels.name> wrote:
>>  >>  I have a setup in which the Server IP is known, whereas the Client IP is changing. Thus, I rely on the Client to connect to the Server. I want the Client to keep the connection alive all the time though, so that the Server can also initiate a connection to the Server when needed. Both, client and server are behind a NAT/Router.
>>  >>  I would think, that the "PersistentKeepalive = 25" on the Client would ckeep the connection open. The connection works fine while used. But after a while, I cannot connect from the Server to the client anymore.
>>  >>  I would assume that a ping from the Client to the IP of the endpoint would help to re-alive the connection - but it does not.
>>  >>
>>  >>  Only after a wg-quick down and up all is fine again.
>>  >>
>>  >>  Below some more information.
>>  >>
>>  >>  Can you help me to find, what I am doing wrong?
>>
>>  _______________________________________________
>>  WireGuard mailing list
>>  WireGuard@lists.zx2c4.com
>>  https://lists.zx2c4.com/mailman/listinfo/wireguard

[-- Attachment #1.2: Type: text/html, Size: 5773 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Keep-alive does not keep the connection alive

[Laszlo KERTESZ]

[-- Attachment #1.1: Type: text/plain, Size: 2652 bytes --]

I too use a server with dynamic ip. And the clients (Android, Linux) tend
to lose connectivity permanently if the server's ip changes. With or
without keepalive.

The dynamic ip's dns entries are updated almost instantly when the ip
changes so this is not dns related. Wireguard does not try to re establish
connection, it keeps using the server ip acquired at the tunnel's start.
Only way around this is restarting the interface.

On Mon, Aug 26, 2019, 21:08 Ivan Labáth <labawi-wg@matrix-dream.net> wrote:

> Hello,
>
> I notice you are using dynamic ips for server.
> On the client, is the server peer ip correct?
>
> Regards,
> Ivan
>
> On Sun, Aug 25, 2019 at 06:44:53PM +0000, Hendrik Friedel wrote:
> > Hello,
> >
> > thanks for your reply.
> > It is linux (Kernel 5.x) in both cases.
> >
> > Regards,
> > Hendrik
> >
> > ------ Originalnachricht ------
> > Von: "Vasili Pupkin" <diggest@gmail.com>
> > An: "Hendrik Friedel" <hendrik@friedels.name>
> > Cc: wireguard@lists.zx2c4.com
> > Gesendet: 25.08.2019 17:59:59
> > Betreff: Re: Keep-alive does not keep the connection alive
> >
> > >What OS is running on client side? I have this issue on Win7 client,
> > >can explain it further, it has nothing to do with keepalives though,
> > >it is a bug in tun adapter implementation
> > >
> > >On Sun, Aug 25, 2019 at 6:38 PM Hendrik Friedel <hendrik@friedels.name>
> wrote:
> > >>  I have a setup in which the Server IP is known, whereas the Client
> IP is changing. Thus, I rely on the Client to connect to the Server. I want
> the Client to keep the connection alive all the time though, so that the
> Server can also initiate a connection to the Server when needed. Both,
> client and server are behind a NAT/Router.
> > >>  I would think, that the "PersistentKeepalive = 25" on the Client
> would ckeep the connection open. The connection works fine while used. But
> after a while, I cannot connect from the Server to the client anymore.
> > >>  I would assume that a ping from the Client to the IP of the endpoint
> would help to re-alive the connection - but it does not.
> > >>
> > >>  Only after a wg-quick down and up all is fine again.
> > >>
> > >>  Below some more information.
> > >>
> > >>  Can you help me to find, what I am doing wrong?
> >
> > _______________________________________________
> > WireGuard mailing list
> > WireGuard@lists.zx2c4.com
> > https://lists.zx2c4.com/mailman/listinfo/wireguard
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

[-- Attachment #1.2: Type: text/html, Size: 3951 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re[2]: Keep-alive does not keep the connection alive

[Hendrik Friedel]

[-- Attachment #1.1: Type: text/plain, Size: 3469 bytes --]

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.


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?

Regards,
Hendrik

------ Originalnachricht ------
Von: "Laszlo KERTESZ" <laszlo.kertesz@gmail.com>
An: "Ivan Labáth" <labawi-wg@matrix-dream.net>
Cc: "Hendrik Friedel" <hendrik@friedels.name>; wireguard@lists.zx2c4.com
Gesendet: 28.08.2019 08:17:32
Betreff: Re: Keep-alive does not keep the connection alive

>I too use a server with dynamic ip. And the clients (Android, Linux) 
>tend to lose connectivity permanently if the server's ip changes. With 
>or without keepalive.
>
>The dynamic ip's dns entries are updated almost instantly when the ip 
>changes so this is not dns related. Wireguard does not try to re 
>establish connection, it keeps using the server ip acquired at the 
>tunnel's start. Only way around this is restarting the interface.
>
>On Mon, Aug 26, 2019, 21:08 Ivan Labáth <labawi-wg@matrix-dream.net> 
>wrote:
>>Hello,
>>
>>I notice you are using dynamic ips for server.
>>On the client, is the server peer ip correct?
>>
>>Regards,
>>Ivan
>>
>>On Sun, Aug 25, 2019 at 06:44:53PM +0000, Hendrik Friedel wrote:
>> > Hello,
>> >
>> > thanks for your reply.
>> > It is linux (Kernel 5.x) in both cases.
>> >
>> > Regards,
>> > Hendrik
>> >
>> > ------ Originalnachricht ------
>> > Von: "Vasili Pupkin" <diggest@gmail.com>
>> > An: "Hendrik Friedel" <hendrik@friedels.name>
>> > Cc: wireguard@lists.zx2c4.com
>> > Gesendet: 25.08.2019 17:59:59
>> > Betreff: Re: Keep-alive does not keep the connection alive
>> >
>> > >What OS is running on client side? I have this issue on Win7 
>>client,
>> > >can explain it further, it has nothing to do with keepalives 
>>though,
>> > >it is a bug in tun adapter implementation
>> > >
>> > >On Sun, Aug 25, 2019 at 6:38 PM Hendrik Friedel 
>><hendrik@friedels.name> wrote:
>> > >>  I have a setup in which the Server IP is known, whereas the 
>>Client IP is changing. Thus, I rely on the Client to connect to the 
>>Server. I want the Client to keep the connection alive all the time 
>>though, so that the Server can also initiate a connection to the 
>>Server when needed. Both, client and server are behind a NAT/Router.
>> > >>  I would think, that the "PersistentKeepalive = 25" on the Client 
>>would ckeep the connection open. The connection works fine while used. 
>>But after a while, I cannot connect from the Server to the client 
>>anymore.
>> > >>  I would assume that a ping from the Client to the IP of the 
>>endpoint would help to re-alive the connection - but it does not.
>> > >>
>> > >>  Only after a wg-quick down and up all is fine again.
>> > >>
>> > >>  Below some more information.
>> > >>
>> > >>  Can you help me to find, what I am doing wrong?
>> >
>> > _______________________________________________
>> > WireGuard mailing list
>> > WireGuard@lists.zx2c4.com
>> > https://lists.zx2c4.com/mailman/listinfo/wireguard
>>_______________________________________________
>>WireGuard mailing list
>>WireGuard@lists.zx2c4.com
>>https://lists.zx2c4.com/mailman/listinfo/wireguard

[-- Attachment #1.2: Type: text/html, Size: 5865 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Re[2]: Keep-alive does not keep the connection alive

[Laszlo KERTESZ]

[-- Attachment #1.1: Type: text/plain, Size: 4177 bytes --]

The thing is i don't know what is 'reconnect' from WG's point of view. It
is 'stateless' of sorts as far as I know and it does not have if down/up
behavior like openvpn or other ssl vpn's that have keepalives. By default
it just sends packets and the optional keepalives are only there to help
with firewall traversal and such, it is not used to track the tunnel's
functionality.

It should have some internal counter that will re-try dns resolution after
some sort of timeout. Another important aspect is that this should work
even without keepalives somehow.

On Wed, Aug 28, 2019, 09:25 Hendrik Friedel <hendrik@friedels.name> 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.
>
>
> 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?
>
> Regards,
> Hendrik
>
> ------ Originalnachricht ------
> Von: "Laszlo KERTESZ" <laszlo.kertesz@gmail.com>
> An: "Ivan Labáth" <labawi-wg@matrix-dream.net>
> Cc: "Hendrik Friedel" <hendrik@friedels.name>; wireguard@lists.zx2c4.com
> Gesendet: 28.08.2019 08:17:32
> Betreff: Re: Keep-alive does not keep the connection alive
>
> I too use a server with dynamic ip. And the clients (Android, Linux) tend
> to lose connectivity permanently if the server's ip changes. With or
> without keepalive.
>
> The dynamic ip's dns entries are updated almost instantly when the ip
> changes so this is not dns related. Wireguard does not try to re establish
> connection, it keeps using the server ip acquired at the tunnel's start.
> Only way around this is restarting the interface.
>
> On Mon, Aug 26, 2019, 21:08 Ivan Labáth <labawi-wg@matrix-dream.net>
> wrote:
>
>> Hello,
>>
>> I notice you are using dynamic ips for server.
>> On the client, is the server peer ip correct?
>>
>> Regards,
>> Ivan
>>
>> On Sun, Aug 25, 2019 at 06:44:53PM +0000, Hendrik Friedel wrote:
>> > Hello,
>> >
>> > thanks for your reply.
>> > It is linux (Kernel 5.x) in both cases.
>> >
>> > Regards,
>> > Hendrik
>> >
>> > ------ Originalnachricht ------
>> > Von: "Vasili Pupkin" <diggest@gmail.com>
>> > An: "Hendrik Friedel" <hendrik@friedels.name>
>> > Cc: wireguard@lists.zx2c4.com
>> > Gesendet: 25.08.2019 17:59:59
>> > Betreff: Re: Keep-alive does not keep the connection alive
>> >
>> > >What OS is running on client side? I have this issue on Win7 client,
>> > >can explain it further, it has nothing to do with keepalives though,
>> > >it is a bug in tun adapter implementation
>> > >
>> > >On Sun, Aug 25, 2019 at 6:38 PM Hendrik Friedel <hendrik@friedels.name>
>> wrote:
>> > >>  I have a setup in which the Server IP is known, whereas the Client
>> IP is changing. Thus, I rely on the Client to connect to the Server. I want
>> the Client to keep the connection alive all the time though, so that the
>> Server can also initiate a connection to the Server when needed. Both,
>> client and server are behind a NAT/Router.
>> > >>  I would think, that the "PersistentKeepalive = 25" on the Client
>> would ckeep the connection open. The connection works fine while used. But
>> after a while, I cannot connect from the Server to the client anymore.
>> > >>  I would assume that a ping from the Client to the IP of the
>> endpoint would help to re-alive the connection - but it does not.
>> > >>
>> > >>  Only after a wg-quick down and up all is fine again.
>> > >>
>> > >>  Below some more information.
>> > >>
>> > >>  Can you help me to find, what I am doing wrong?
>> >
>> > _______________________________________________
>> > WireGuard mailing list
>> > WireGuard@lists.zx2c4.com
>> > https://lists.zx2c4.com/mailman/listinfo/wireguard
>> _______________________________________________
>> WireGuard mailing list
>> WireGuard@lists.zx2c4.com
>> https://lists.zx2c4.com/mailman/listinfo/wireguard
>>
>

[-- Attachment #1.2: Type: text/html, Size: 6693 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Keep-alive does not keep the connection alive

[Ivan Labáth]

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

Re: Keep-alive does not keep the connection alive

[Laszlo KERTESZ]

[-- Attachment #1.1: Type: text/plain, Size: 564 bytes --]

> 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
>

Keepalive does not seem to work in my experience.
On Linux i set up a recurrent script that tests connection to the wg tunnel
gateway and restarts the connection if the connection test fails.
But on Android this is not possible without additional tools running in
background that will use battery and negate wireguard's benefits.

[-- Attachment #1.2: Type: text/html, Size: 895 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re[2]: Keep-alive does not keep the connection alive

[Hendrik Friedel]

[-- Attachment #1.1: Type: text/plain, Size: 1855 bytes --]

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?
>

>
>>  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 
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'.
>

>
>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


>




>

[-- Attachment #1.2: Type: text/html, Size: 5235 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Keep-alive does not keep the connection alive

[Ivan Labáth]

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

Re: Keep-alive does not keep the connection alive

[Vincent Wiemann]

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:
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.

> 
> 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

Best,
Vincent
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re[2]: Keep-alive does not keep the connection alive

[Hendrik Friedel]

[-- 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

Re: Keep-alive does not keep the connection alive

[Ivan Labáth]

On Thu, Oct 17, 2019 at 07:03:40PM +0000, Hendrik Friedel wrote:
> >>
> >>  >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?

wg set <interface> [listen-port <port>] [fwmark <mark>] [private-key <file path>] [peer <base64 public key> [remove] [preshared-key <file path>] [endpoint <ip>:<port>] [persistent-keepalive <interval seconds>] [allowed-ips <ip1>/<cidr1>[,<ip2>/<cidr2>]...] ]...

so something like:
wg set <wgiface> peer <peerpubkey> endpoint <ip>:<port>

> >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?

Yes, either of those.

--
Ivan
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard