WireGuard Archive on lore.kernel.org
 help / color / Atom feed
* Keep-alive does not keep the connection alive
@ 2019-08-21 19:13 Hendrik Friedel
       [not found] ` <CANH_QeYQ7hyBG1qK9PJB9E77gggW0NYe70vv8m6Dn=fU5zHQbg@mail.gmail.com>
  0 siblings, 1 reply; 14+ messages in thread
From: Hendrik Friedel @ 2019-08-21 19:13 UTC (permalink / raw)
  To: wireguard

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

<html><head><style>#x8cab70c1932b41039c428c4731604d81{
	font-family:'Segoe UI';
	font-size:12pt;
}</style>

<style id="css_styles">
blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; }
a img { border: 0px; }
li[style='text-align: center;'], li[style='text-align: right;'] {  list-style-position: inside;}
body { font-family: Segoe UI; font-size: 12pt;   }
</style>
</head>
<body>Hello,<div><br /></div><div>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.</div><div>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.</div><div>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.</div><div><br /></div><div>Only after a wg-quick down and up all is fine again.</div><div><br /></div><div>Below some more information.</div><div><br /></div><div>Can you help me to find, what I am doing wrong?</div><div><br /></div><div>Regards,</div><div>Hendrik</div><div><br /></div><div><br /></div><div><br /></div><div>At the time of the problem "wg" shows on the Client:</div><div>interface: wgnet0<br />  public key: cebXSxxx=<br />  private key: (hidden)<br />  listening port: 60147<br />  fwmark: 0xca6c<br /><br />peer:  oNjoixxx=<br />  endpoint: 92.210.7.177:51820<br />  allowed ips: 0.0.0.0/0<br />  latest handshake: 1 day, 7 hours, 44 minutes, 19 seconds ago<br />  transfer: 48.48 GiB received, 1.22 TiB sent<br />  persistent keepalive: every 25 seconds<br /></div><div><br /></div><div><br /></div><div>and on the Server</div><div> wg<br />interface: wgnet0<br />  public key: oNjoijXxxx=</div><div>  private key: (hidden)<br />  listening port: 51820<br /><br />peer: cebXSxx=<br />  endpoint: 185.22.142.254:60147<br />  allowed ips: 10.192.122.3/32<br />  latest handshake: 1 day, 7 hours, 46 minutes, 5 seconds ago<br />  transfer: 67.24 MiB received, 651.37 MiB sent<br /><br />peer: ZiTlYnxx=<br />  endpoint: 109.41.65.27:5935<br />  allowed ips: 10.192.122.2/32<br />  latest handshake: 2 days, 21 hours, 49 minutes, 25 seconds ago<br />  transfer: 11.98 MiB received, 127.11 MiB sent<br /></div><div><br /></div><div><br /></div><div>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.</div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div>The Client config:</div><div>[Interface]</div><div>Address = 10.192.122.3/32</div><div>PrivateKey = xx=</div><div><br /></div><div>[Peer]</div><div>PublicKey = yy=</div><div>Endpoint = Dyn.IP:51820</div><div>AllowedIPs = 0.0.0.0/0</div><div>PersistentKeepalive = 25</div><div><br /></div><div>The Server config:</div><div>[Interface]</div><div>Address = 10.192.122.1/24</div><div>SaveConfig = true</div><div>PostUp = iptables -A FORWARD -i wgnet0 -j ACCEPT; iptables -A FORWARD -o wgnet0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE</div><div>PostDown = iptables -D FORWARD -i wgnet0 -j ACCEPT; iptables -D FORWARD -o wgnet0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE</div><div>ListenPort = 51820</div><div>PrivateKey = aa=</div><div><br /></div><div>[Peer]</div><div>PublicKey = bb=</div><div>AllowedIPs = 10.192.122.2/32</div><div>Endpoint = hidden:41646</div><div><br /></div><div>[Peer]</div><div>PublicKey = cc=</div><div>AllowedIPs = 10.192.122.3/32</div><div>Endpoint = hidden:60147</div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div></body></html>

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

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re[2]: Keep-alive does not keep the connection alive
       [not found] ` <CANH_QeYQ7hyBG1qK9PJB9E77gggW0NYe70vv8m6Dn=fU5zHQbg@mail.gmail.com>
@ 2019-08-25 18:44   ` " Hendrik Friedel
  2019-08-26 18:02     ` Ivan Labáth
  0 siblings, 1 reply; 14+ messages in thread
From: Hendrik Friedel @ 2019-08-25 18:44 UTC (permalink / raw)
  To: Vasili Pupkin; +Cc: wireguard

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Keep-alive does not keep the connection alive
  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
  0 siblings, 2 replies; 14+ messages in thread
From: Ivan Labáth @ 2019-08-26 18:02 UTC (permalink / raw)
  To: Hendrik Friedel; +Cc: wireguard

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re[2]: Keep-alive does not keep the connection alive
  2019-08-26 18:02     ` Ivan Labáth
@ 2019-08-28  6:06       ` " Hendrik Friedel
  2019-08-28  6:17       ` Laszlo KERTESZ
  1 sibling, 0 replies; 14+ messages in thread
From: Hendrik Friedel @ 2019-08-28  6:06 UTC (permalink / raw)
  To: Ivan Labáth; +Cc: wireguard

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

<html><head><style>#x4378ac1a8d5e4bd79733224344e79ff8{
	font-family:'Segoe UI';
	font-size:12pt;
	color:#000;
	margin-left:0px;
	margin-right:8px;
	background-color:#FFF;
}
#x4378ac1a8d5e4bd79733224344e79ff8{
	font-family:'Segoe UI';
	font-size:12pt;
}#xe2c1111c7c8047e6b2382a2787faad5a{
	font-family:'Segoe UI';
	font-size:12pt;
	color:#000;
	margin-left:0px;
	margin-right:8px;
	background-color:#FFF;
}
#xe2c1111c7c8047e6b2382a2787faad5a{
	font-family:'Segoe UI';
	font-size:12pt;
}</style>

<style id="css_styles" type="text/css">blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; }
a img { border: 0px; }
li[style='text-align: center;'], li[style='text-align: right;'] {  list-style-position: inside;}
body { font-family: Segoe UI; font-size: 12pt;   }</style></head><body class="plain"><div>Hello,</div><div><br /></div><div>yes, the Sever has a dynamic IP.</div><div><br /></div><div>&gt;On the client, is the server peer ip correct?</div><div>Which entry are you refering to?</div><div><div id="xe2c1111c7c8047e6b2382a2787faad5a"><div style="zoom: 0.9;"><div>I assume </div><div>Endpoint = Dyn.IP:51820 </div><div><br /></div><div>Yes, but otherwise, the connection would not even be established, right?</div><div><br /></div><div>For reference, here the complete client config:</div><div><div id="x4378ac1a8d5e4bd79733224344e79ff8"><div><div>[Interface]</div><div>Address = 10.192.122.3/32</div><div>PrivateKey = xx=</div><div><br /></div><div>[Peer]</div><div>PublicKey = yy=</div><div>Endpoint = Dyn.IP:51820</div><div>AllowedIPs = 0.0.0.0/0</div><div>PersistentKeepalive = 25</div></div></div></div><div><br /></div><div>Regards,</div><div>Hendrik</div><div><br /></div></div></div></div><div><br /></div>
<div><br /></div>
<div>------ Originalnachricht ------</div>
<div>Von: "Ivan Labáth" &lt;labawi-wg@matrix-dream.net&gt;</div>
<div>An: "Hendrik Friedel" &lt;hendrik@friedels.name&gt;</div>
<div>Cc: "Vasili Pupkin" &lt;diggest@gmail.com&gt;; wireguard@lists.zx2c4.com</div>
<div>Gesendet: 26.08.2019 20:02:44</div>
<div>Betreff: Re: Keep-alive does not keep the connection alive</div><div><br /></div>
<div id="x5ecd9e8c2fd143e"><blockquote type="cite" class="cite2">

<div class="plain_line">Hello,</div>
<div class="plain_line"> </div>
<div class="plain_line">I notice you are using dynamic ips for server.</div>
<div class="plain_line">On the client, is the server peer ip correct?</div>
<div class="plain_line"> </div>
<div class="plain_line">Regards,</div>
<div class="plain_line">Ivan</div>
<div class="plain_line"> </div>
<div class="plain_line">On Sun, Aug 25, 2019 at 06:44:53PM +0000, Hendrik Friedel wrote:</div>
<blockquote type="cite" class="cite">
<div class="plain_line"> Hello,</div>
<div class="plain_line"> </div>
<div class="plain_line"> thanks for your reply.</div>
<div class="plain_line"> It is linux (Kernel 5.x) in both cases.</div>
<div class="plain_line"> </div>
<div class="plain_line"> Regards,</div>
<div class="plain_line"> Hendrik</div>
<div class="plain_line"> </div>
<div class="plain_line"> ------ Originalnachricht ------</div>
<div class="plain_line"> Von: "Vasili Pupkin" &lt;diggest@gmail.com&gt;</div>
<div class="plain_line"> An: "Hendrik Friedel" &lt;hendrik@friedels.name&gt;</div>
<div class="plain_line"> Cc: wireguard@lists.zx2c4.com</div>
<div class="plain_line"> Gesendet: 25.08.2019 17:59:59</div>
<div class="plain_line"> Betreff: Re: Keep-alive does not keep the connection alive</div>
<div class="plain_line"> </div>
<div class="plain_line"> &gt;What OS is running on client side? I have this issue on Win7 client,</div>
<div class="plain_line"> &gt;can explain it further, it has nothing to do with keepalives though,</div>
<div class="plain_line"> &gt;it is a bug in tun adapter implementation</div>
<div class="plain_line"> &gt;</div>
<div class="plain_line"> &gt;On Sun, Aug 25, 2019 at 6:38 PM Hendrik Friedel &lt;hendrik@friedels.name&gt; wrote:</div>
<div class="plain_line"> &gt;&gt;  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.</div>
<div class="plain_line"> &gt;&gt;  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.</div>
<div class="plain_line"> &gt;&gt;  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.</div>
<div class="plain_line"> &gt;&gt;</div>
<div class="plain_line"> &gt;&gt;  Only after a wg-quick down and up all is fine again.</div>
<div class="plain_line"> &gt;&gt;</div>
<div class="plain_line"> &gt;&gt;  Below some more information.</div>
<div class="plain_line"> &gt;&gt;</div>
<div class="plain_line"> &gt;&gt;  Can you help me to find, what I am doing wrong?</div>
<div class="plain_line"> </div>
<div class="plain_line"> _______________________________________________</div>
<div class="plain_line"> WireGuard mailing list</div>
<div class="plain_line"> WireGuard@lists.zx2c4.com</div>
<div class="plain_line"> https://lists.zx2c4.com/mailman/listinfo/wireguard</div>
</blockquote>
</blockquote></div>
</body></html>

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

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Keep-alive does not keep the connection alive
  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
  1 sibling, 1 reply; 14+ messages in thread
From: Laszlo KERTESZ @ 2019-08-28  6:17 UTC (permalink / raw)
  To: Ivan Labáth; +Cc: wireguard

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

<div dir="auto">I too use a server with dynamic ip. And the clients (Android, Linux) tend to lose connectivity permanently if the server&#39;s ip changes. With or without keepalive.<div dir="auto"><br></div><div dir="auto">The dynamic ip&#39;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&#39;s start. Only way around this is restarting the interface. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 26, 2019, 21:08 Ivan Labáth &lt;<a href="mailto:labawi-wg@matrix-dream.net">labawi-wg@matrix-dream.net</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I notice you are using dynamic ips for server.<br>
On the client, is the server peer ip correct?<br>
<br>
Regards,<br>
Ivan<br>
<br>
On Sun, Aug 25, 2019 at 06:44:53PM +0000, Hendrik Friedel wrote:<br>
&gt; Hello,<br>
&gt; <br>
&gt; thanks for your reply.<br>
&gt; It is linux (Kernel 5.x) in both cases.<br>
&gt; <br>
&gt; Regards,<br>
&gt; Hendrik<br>
&gt; <br>
&gt; ------ Originalnachricht ------<br>
&gt; Von: &quot;Vasili Pupkin&quot; &lt;<a href="mailto:diggest@gmail.com" target="_blank" rel="noreferrer">diggest@gmail.com</a>&gt;<br>
&gt; An: &quot;Hendrik Friedel&quot; &lt;<a href="mailto:hendrik@friedels.name" target="_blank" rel="noreferrer">hendrik@friedels.name</a>&gt;<br>
&gt; Cc: <a href="mailto:wireguard@lists.zx2c4.com" target="_blank" rel="noreferrer">wireguard@lists.zx2c4.com</a><br>
&gt; Gesendet: 25.08.2019 17:59:59<br>
&gt; Betreff: Re: Keep-alive does not keep the connection alive<br>
&gt; <br>
&gt; &gt;What OS is running on client side? I have this issue on Win7 client,<br>
&gt; &gt;can explain it further, it has nothing to do with keepalives though,<br>
&gt; &gt;it is a bug in tun adapter implementation<br>
&gt; &gt;<br>
&gt; &gt;On Sun, Aug 25, 2019 at 6:38 PM Hendrik Friedel &lt;<a href="mailto:hendrik@friedels.name" target="_blank" rel="noreferrer">hendrik@friedels.name</a>&gt; wrote:<br>
&gt; &gt;&gt;  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.<br>
&gt; &gt;&gt;  I would think, that the &quot;PersistentKeepalive = 25&quot; 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.<br>
&gt; &gt;&gt;  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.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;  Only after a wg-quick down and up all is fine again.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;  Below some more information.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;  Can you help me to find, what I am doing wrong?<br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; WireGuard mailing list<br>
&gt; <a href="mailto:WireGuard@lists.zx2c4.com" target="_blank" rel="noreferrer">WireGuard@lists.zx2c4.com</a><br>
&gt; <a href="https://lists.zx2c4.com/mailman/listinfo/wireguard" rel="noreferrer noreferrer" target="_blank">https://lists.zx2c4.com/mailman/listinfo/wireguard</a><br>
_______________________________________________<br>
WireGuard mailing list<br>
<a href="mailto:WireGuard@lists.zx2c4.com" target="_blank" rel="noreferrer">WireGuard@lists.zx2c4.com</a><br>
<a href="https://lists.zx2c4.com/mailman/listinfo/wireguard" rel="noreferrer noreferrer" target="_blank">https://lists.zx2c4.com/mailman/listinfo/wireguard</a><br>
</blockquote></div>

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

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re[2]: Keep-alive does not keep the connection alive
  2019-08-28  6:17       ` Laszlo KERTESZ
@ 2019-08-28  6:25         ` " Hendrik Friedel
  2019-08-28  6:37           ` Laszlo KERTESZ
  2019-08-28  6:54           ` Ivan Labáth
  0 siblings, 2 replies; 14+ messages in thread
From: Hendrik Friedel @ 2019-08-28  6:25 UTC (permalink / raw)
  To: Laszlo KERTESZ, Ivan Labáth; +Cc: wireguard

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

<html><head><style id="css_styles" type="text/css">blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; }
a img { border: 0px; }
li[style='text-align: center;'], li[style='text-align: right;'] {  list-style-position: inside;}
body { font-family: Segoe UI; font-size: 12pt;   }</style></head><body><div>Hello,</div><div><br /></div><div>that seems not to be the intended behaviour:</div><div>If I understand correctly, the current behaviour is:</div><div><br /></div><div>At tunnel start the IP is resolved</div><div>This IP is used for ever, namingly for re-connects.</div><div><br /></div><div><br /></div><div>The probably intended behaviour would be:</div><div><br /></div><div>At tunnel start and at any re-connect the IP is resolved.</div><div><br /></div><div><br /></div><div>Do you agree that this behaviour should be changed? </div><div>Apart from that: Can you suggest an automatable workaround?</div><div><br /></div><div>Regards,</div><div>Hendrik</div>
<div><br /></div>
<div>------ Originalnachricht ------</div>
<div>Von: "Laszlo KERTESZ" &lt;<a href="mailto:laszlo.kertesz@gmail.com">laszlo.kertesz@gmail.com</a>&gt;</div>
<div>An: "Ivan Labáth" &lt;<a href="mailto:labawi-wg@matrix-dream.net">labawi-wg@matrix-dream.net</a>&gt;</div>
<div>Cc: "Hendrik Friedel" &lt;<a href="mailto:hendrik@friedels.name">hendrik@friedels.name</a>&gt;; <a href="mailto:wireguard@lists.zx2c4.com">wireguard@lists.zx2c4.com</a></div>
<div>Gesendet: 28.08.2019 08:17:32</div>
<div>Betreff: Re: Keep-alive does not keep the connection alive</div><div><br /></div>
<div id="x67c9270ef9284da"><blockquote cite="CANcuY=oE9L_sm1b_JJV4_fv+ABLx9ZbTeXXzijkiLw-b=CxkMQ@mail.gmail.com" type="cite" class="cite2">
<div dir="auto">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.<div dir="auto"><br /></div><div dir="auto">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. </div></div><br /><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 26, 2019, 21:08 Ivan Labáth &lt;<a href="mailto:labawi-wg@matrix-dream.net">labawi-wg@matrix-dream.net</a>&gt; wrote:<br /></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br />
<br />
I notice you are using dynamic ips for server.<br />
On the client, is the server peer ip correct?<br />
<br />
Regards,<br />
Ivan<br />
<br />
On Sun, Aug 25, 2019 at 06:44:53PM +0000, Hendrik Friedel wrote:<br />
&gt; Hello,<br />
&gt; <br />
&gt; thanks for your reply.<br />
&gt; It is linux (Kernel 5.x) in both cases.<br />
&gt; <br />
&gt; Regards,<br />
&gt; Hendrik<br />
&gt; <br />
&gt; ------ Originalnachricht ------<br />
&gt; Von: "Vasili Pupkin" &lt;<a href="mailto:diggest@gmail.com" rel="noreferrer">diggest@gmail.com</a>&gt;<br />
&gt; An: "Hendrik Friedel" &lt;<a href="mailto:hendrik@friedels.name" rel="noreferrer">hendrik@friedels.name</a>&gt;<br />
&gt; Cc: <a href="mailto:wireguard@lists.zx2c4.com" rel="noreferrer">wireguard@lists.zx2c4.com</a><br />
&gt; Gesendet: 25.08.2019 17:59:59<br />
&gt; Betreff: Re: Keep-alive does not keep the connection alive<br />
&gt; <br />
&gt; &gt;What OS is running on client side? I have this issue on Win7 client,<br />
&gt; &gt;can explain it further, it has nothing to do with keepalives though,<br />
&gt; &gt;it is a bug in tun adapter implementation<br />
&gt; &gt;<br />
&gt; &gt;On Sun, Aug 25, 2019 at 6:38 PM Hendrik Friedel &lt;<a href="mailto:hendrik@friedels.name" rel="noreferrer">hendrik@friedels.name</a>&gt; wrote:<br />
&gt; &gt;&gt;  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.<br />
&gt; &gt;&gt;  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.<br />
&gt; &gt;&gt;  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.<br />
&gt; &gt;&gt;<br />
&gt; &gt;&gt;  Only after a wg-quick down and up all is fine again.<br />
&gt; &gt;&gt;<br />
&gt; &gt;&gt;  Below some more information.<br />
&gt; &gt;&gt;<br />
&gt; &gt;&gt;  Can you help me to find, what I am doing wrong?<br />
&gt; <br />
&gt; _______________________________________________<br />
&gt; WireGuard mailing list<br />
&gt; <a href="mailto:WireGuard@lists.zx2c4.com" rel="noreferrer">WireGuard@lists.zx2c4.com</a><br />
&gt; <a href="https://lists.zx2c4.com/mailman/listinfo/wireguard" rel="noreferrer noreferrer">https://lists.zx2c4.com/mailman/listinfo/wireguard</a><br />
_______________________________________________<br />
WireGuard mailing list<br />
<a href="mailto:WireGuard@lists.zx2c4.com" rel="noreferrer">WireGuard@lists.zx2c4.com</a><br />
<a href="https://lists.zx2c4.com/mailman/listinfo/wireguard" rel="noreferrer noreferrer">https://lists.zx2c4.com/mailman/listinfo/wireguard</a><br />
</blockquote></div>
</blockquote></div>
</body></html>

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

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Re[2]: Keep-alive does not keep the connection alive
  2019-08-28  6:25         ` Re[2]: " Hendrik Friedel
@ 2019-08-28  6:37           ` Laszlo KERTESZ
  2019-08-28  6:54           ` Ivan Labáth
  1 sibling, 0 replies; 14+ messages in thread
From: Laszlo KERTESZ @ 2019-08-28  6:37 UTC (permalink / raw)
  To: Hendrik Friedel; +Cc: wireguard

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

<div dir="auto">The thing is i don&#39;t know what is &#39;reconnect&#39; from WG&#39;s point of view. It is &#39;stateless&#39; of sorts as far as I know and it does not have if down/up behavior like openvpn or other ssl vpn&#39;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&#39;s functionality. <div dir="auto"><br></div><div dir="auto">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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 28, 2019, 09:25 Hendrik Friedel &lt;<a href="mailto:hendrik@friedels.name">hendrik@friedels.name</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Hello,</div><div><br></div><div>that seems not to be the intended behaviour:</div><div>If I understand correctly, the current behaviour is:</div><div><br></div><div>At tunnel start the IP is resolved</div><div>This IP is used for ever, namingly for re-connects.</div><div><br></div><div><br></div><div>The probably intended behaviour would be:</div><div><br></div><div>At tunnel start and at any re-connect the IP is resolved.</div><div><br></div><div><br></div><div>Do you agree that this behaviour should be changed? </div><div>Apart from that: Can you suggest an automatable workaround?</div><div><br></div><div>Regards,</div><div>Hendrik</div>
<div><br></div>
<div>------ Originalnachricht ------</div>
<div>Von: &quot;Laszlo KERTESZ&quot; &lt;<a href="mailto:laszlo.kertesz@gmail.com" target="_blank" rel="noreferrer">laszlo.kertesz@gmail.com</a>&gt;</div>
<div>An: &quot;Ivan Labáth&quot; &lt;<a href="mailto:labawi-wg@matrix-dream.net" target="_blank" rel="noreferrer">labawi-wg@matrix-dream.net</a>&gt;</div>
<div>Cc: &quot;Hendrik Friedel&quot; &lt;<a href="mailto:hendrik@friedels.name" target="_blank" rel="noreferrer">hendrik@friedels.name</a>&gt;; <a href="mailto:wireguard@lists.zx2c4.com" target="_blank" rel="noreferrer">wireguard@lists.zx2c4.com</a></div>
<div>Gesendet: 28.08.2019 08:17:32</div>
<div>Betreff: Re: Keep-alive does not keep the connection alive</div><div><br></div>
<div id="m_-4266857512841702538x67c9270ef9284da"><blockquote cite="http://CANcuY=oE9L_sm1b_JJV4_fv+ABLx9ZbTeXXzijkiLw-b=CxkMQ@mail.gmail.com" type="cite" class="m_-4266857512841702538cite2">
<div dir="auto">I too use a server with dynamic ip. And the clients (Android, Linux) tend to lose connectivity permanently if the server&#39;s ip changes. With or without keepalive.<div dir="auto"><br></div><div dir="auto">The dynamic ip&#39;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&#39;s start. Only way around this is restarting the interface. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 26, 2019, 21:08 Ivan Labáth &lt;<a href="mailto:labawi-wg@matrix-dream.net" target="_blank" rel="noreferrer">labawi-wg@matrix-dream.net</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I notice you are using dynamic ips for server.<br>
On the client, is the server peer ip correct?<br>
<br>
Regards,<br>
Ivan<br>
<br>
On Sun, Aug 25, 2019 at 06:44:53PM +0000, Hendrik Friedel wrote:<br>
&gt; Hello,<br>
&gt; <br>
&gt; thanks for your reply.<br>
&gt; It is linux (Kernel 5.x) in both cases.<br>
&gt; <br>
&gt; Regards,<br>
&gt; Hendrik<br>
&gt; <br>
&gt; ------ Originalnachricht ------<br>
&gt; Von: &quot;Vasili Pupkin&quot; &lt;<a href="mailto:diggest@gmail.com" rel="noreferrer noreferrer" target="_blank">diggest@gmail.com</a>&gt;<br>
&gt; An: &quot;Hendrik Friedel&quot; &lt;<a href="mailto:hendrik@friedels.name" rel="noreferrer noreferrer" target="_blank">hendrik@friedels.name</a>&gt;<br>
&gt; Cc: <a href="mailto:wireguard@lists.zx2c4.com" rel="noreferrer noreferrer" target="_blank">wireguard@lists.zx2c4.com</a><br>
&gt; Gesendet: 25.08.2019 17:59:59<br>
&gt; Betreff: Re: Keep-alive does not keep the connection alive<br>
&gt; <br>
&gt; &gt;What OS is running on client side? I have this issue on Win7 client,<br>
&gt; &gt;can explain it further, it has nothing to do with keepalives though,<br>
&gt; &gt;it is a bug in tun adapter implementation<br>
&gt; &gt;<br>
&gt; &gt;On Sun, Aug 25, 2019 at 6:38 PM Hendrik Friedel &lt;<a href="mailto:hendrik@friedels.name" rel="noreferrer noreferrer" target="_blank">hendrik@friedels.name</a>&gt; wrote:<br>
&gt; &gt;&gt;  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.<br>
&gt; &gt;&gt;  I would think, that the &quot;PersistentKeepalive = 25&quot; 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.<br>
&gt; &gt;&gt;  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.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;  Only after a wg-quick down and up all is fine again.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;  Below some more information.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;  Can you help me to find, what I am doing wrong?<br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; WireGuard mailing list<br>
&gt; <a href="mailto:WireGuard@lists.zx2c4.com" rel="noreferrer noreferrer" target="_blank">WireGuard@lists.zx2c4.com</a><br>
&gt; <a href="https://lists.zx2c4.com/mailman/listinfo/wireguard" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.zx2c4.com/mailman/listinfo/wireguard</a><br>
_______________________________________________<br>
WireGuard mailing list<br>
<a href="mailto:WireGuard@lists.zx2c4.com" rel="noreferrer noreferrer" target="_blank">WireGuard@lists.zx2c4.com</a><br>
<a href="https://lists.zx2c4.com/mailman/listinfo/wireguard" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.zx2c4.com/mailman/listinfo/wireguard</a><br>
</blockquote></div>
</blockquote></div>
</div></blockquote></div>

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

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Keep-alive does not keep the connection alive
  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
  1 sibling, 2 replies; 14+ messages in thread
From: Ivan Labáth @ 2019-08-28  6:54 UTC (permalink / raw)
  To: Hendrik Friedel; +Cc: wireguard

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Keep-alive does not keep the connection alive
  2019-08-28  6:54           ` Ivan Labáth
@ 2019-08-28  7:43             ` Laszlo KERTESZ
  2019-09-07 10:04             ` Re[2]: " Hendrik Friedel
  1 sibling, 0 replies; 14+ messages in thread
From: Laszlo KERTESZ @ 2019-08-28  7:43 UTC (permalink / raw)
  To: Ivan Labáth; +Cc: WireGuard mailing list

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

<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As a workaround you could<br>
  - unconditionally periodically update the endpoint<br>
  - monitor last handshake time, when large update endpoint or restart<br>
    tunnel<br>
  - add keepalive to server - it might reduce your downtime<br></blockquote><div><br></div>Keepalive does not seem to work in my experience. <br></div><div class="gmail_quote">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.</div><div class="gmail_quote">But on Android this is not possible without additional tools running in background that will use battery and negate wireguard&#39;s benefits.<br></div><div class="gmail_quote"><br></div></div>

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

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re[2]: Keep-alive does not keep the connection alive
  2019-08-28  6:54           ` Ivan Labáth
  2019-08-28  7:43             ` Laszlo KERTESZ
@ 2019-09-07 10:04             ` " Hendrik Friedel
  2019-09-10  9:19               ` Ivan Labáth
  1 sibling, 1 reply; 14+ messages in thread
From: Hendrik Friedel @ 2019-09-07 10:04 UTC (permalink / raw)
  To: Ivan Labáth; +Cc: wireguard

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

<html><head><style>#x93406428d40e43d5be476ffb5412c83f #x70fb53580d9c415c9d6c4afe5251441b{
	font-family:'Segoe UI';
	font-size:12pt;
}
#x93406428d40e43d5be476ffb5412c83f{
	font-family:'Segoe UI';
	font-size:12pt;
}#x70fb53580d9c415c9d6c4afe5251441b
{font-family: 'Segoe UI'; font-size: 12pt;}
</style>

<style id="css_styles" type="text/css">blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; }
a img { border: 0px; }
li[style='text-align: center;'], li[style='text-align: right;'] {  list-style-position: inside;}
body { font-family: Segoe UI; font-size: 12pt;   }</style></head><body class="plain"><div>Hello,</div><div><br /></div><div id="x1378faaa1981473"><blockquote type="cite" class="cite2"><blockquote type="cite" class="cite"><div class="plain_line"> that seems not to be the intended behaviour:</div>
<div class="plain_line"> If I understand correctly, the current behaviour is:</div>
<div class="plain_line"> </div>
<div class="plain_line"> At tunnel start the IP is resolved</div>
<div class="plain_line"> This IP is used for ever, namingly for re-connects.</div>
</blockquote>
<div class="plain_line">This is only partly correct. The remote endpoint can unconditionally</div>
<div class="plain_line">roam and is updated by any valid packet from a given IP (if I remember</div>
<div class="plain_line">correctly).</div></blockquote><div id="x1378faaa1981473">What does that mean?</div><div id="x1378faaa1981473">Does that mean, that traffic will update the IP so that the problem will not appear?</div><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div></blockquote><br /><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div>
<blockquote type="cite" class="cite2">
<div class="plain_line"> The probably intended behaviour would be:</div>
<div class="plain_line"> At tunnel start and at any re-connect the IP is resolved.</div>
<div class="plain_line"> </div>
<div class="plain_line"> Do you agree that this behaviour should be changed?</div>
<div class="plain_line"> Apart from that: Can you suggest an automatable workaround?</div>
</blockquote>
<div class="plain_line"> </div>
<div class="plain_line">In some circumstances a similar behavior would be a desired.</div></blockquote><div id="x1378faaa1981473"><br /></div><div id="x1378faaa1981473">That's ambigous.</div><div id="x1378faaa1981473">In what circumstances, what behaviour would be desired?</div><div id="x1378faaa1981473"><br /></div><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div>
<div class="plain_line">Wireguard design and implementation is layered (which seems good).</div>
<div class="plain_line">The secure* tunnel, including the kernel module and wg tool seem</div>
<div class="plain_line">to be in a reasonable state, but automation, DNS, key exchange are</div>
<div class="plain_line">out of scope for them. It is meant to be provided by tooling, which is</div>
<div class="plain_line">currently very raw.</div></blockquote><div id="x1378faaa1981473"><br /></div><div id="x1378faaa1981473">I don't understand... </div><div id="x1378faaa1981473">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.</div><div id="x1378faaa1981473">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'.</div><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div></blockquote><br /><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div>
<div class="plain_line">As a workaround you could</div>
<div class="plain_line">  - unconditionally periodically update the endpoint</div></blockquote></div><div id="x1378faaa1981473"><div id="x93406428d40e43d5be476ffb5412c83f"><div class="plain"><div id="x1378faaa1981473"><div id="x70fb53580d9c415c9d6c4afe5251441b"><div class="plain"><div id="x1378faaa1981473">This would break existing transfers without reason.</div></div></div></div></div></div><blockquote type="cite" class="cite2"><div class="plain_line">  - monitor last handshake time, when large update endpoint or restart</div>
<div class="plain_line">    tunnel</div></blockquote>That could be an option.<br /><blockquote type="cite" class="cite2"><div class="plain_line">  - add keepalive to server - it might reduce your downtime</div></blockquote>How would that help?</div><div id="x1378faaa1981473"><br /></div><div id="x1378faaa1981473">Greetings,</div><div id="x1378faaa1981473">Hendrik</div><div id="x1378faaa1981473"><br /></div><div id="x1378faaa1981473"><br /><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div></blockquote><div id="x1378faaa1981473"><br /></div><div id="x1378faaa1981473"></div><div id="x1378faaa1981473"><br /></div><div id="x1378faaa1981473"><br /></div><br /><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div>
</blockquote></div>
</body></html>

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

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Keep-alive does not keep the connection alive
  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
  0 siblings, 2 replies; 14+ messages in thread
From: Ivan Labáth @ 2019-09-10  9:19 UTC (permalink / raw)
  To: Hendrik Friedel; +Cc: wireguard

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Keep-alive does not keep the connection alive
  2019-09-10  9:19               ` Ivan Labáth
@ 2019-09-11 13:28                 ` Vincent Wiemann
  2019-10-17 19:03                 ` Re[2]: " Hendrik Friedel
  1 sibling, 0 replies; 14+ messages in thread
From: Vincent Wiemann @ 2019-09-11 13:28 UTC (permalink / raw)
  To: Ivan Labáth, Hendrik Friedel; +Cc: wireguard

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re[2]: Keep-alive does not keep the connection alive
  2019-09-10  9:19               ` Ivan Labáth
  2019-09-11 13:28                 ` Vincent Wiemann
@ 2019-10-17 19:03                 ` " Hendrik Friedel
  2019-10-20 20:25                   ` Ivan Labáth
  1 sibling, 1 reply; 14+ messages in thread
From: Hendrik Friedel @ 2019-10-17 19:03 UTC (permalink / raw)
  To: Ivan Labáth; +Cc: wireguard

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

<html><head>

<style id="css_styles" type="text/css">blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; }
a img { border: 0px; }
li[style='text-align: center;'], li[style='text-align: right;'] {  list-style-position: inside;}
body { font-family: Segoe UI; font-size: 12pt;   }</style></head><body class="plain"><div>Hello,</div><div><br /></div><div>------ Originalnachricht ------</div>
<div>Von: "Ivan Labáth" &lt;labawi-wg@matrix-dream.net&gt;</div>
<div>An: "Hendrik Friedel" &lt;hendrik@friedels.name&gt;</div>
<div>Cc: "Laszlo KERTESZ" &lt;laszlo.kertesz@gmail.com&gt;; wireguard@lists.zx2c4.com</div>
<div>Gesendet: 10.09.2019 11:19:22</div>
<div>Betreff: Re: Keep-alive does not keep the connection alive</div><div><br /></div>
<div id="x85650cc1b3ab4be"><blockquote type="cite" class="cite2">

<div class="plain_line">On Sat, Sep 07, 2019 at 10:04:44AM +0000, Hendrik Friedel wrote:</div>
<blockquote type="cite" class="cite">
<div class="plain_line"> Hello,</div>
<div class="plain_line"> </div>
<div class="plain_line"> &gt;&gt;  that seems not to be the intended behaviour:</div>
<div class="plain_line"> &gt;&gt;  If I understand correctly, the current behaviour is:</div>
<div class="plain_line"> &gt;&gt;</div>
<div class="plain_line"> &gt;&gt;  At tunnel start the IP is resolved</div>
<div class="plain_line"> &gt;&gt;  This IP is used for ever, namingly for re-connects.</div>
<div class="plain_line"> &gt;This is only partly correct. The remote endpoint can unconditionally</div>
<div class="plain_line"> &gt;roam and is updated by any valid packet from a given IP (if I remember</div>
<div class="plain_line"> &gt;correctly).</div>
<div class="plain_line"> What does that mean?</div>
<div class="plain_line"> Does that mean, that traffic will update the IP so that the problem will</div>
<div class="plain_line"> not appear?</div>
</blockquote>
<div class="plain_line"> </div>
<div class="plain_line">If you have peers A and B with publicly rechable IP+port A1 and B1.</div>
<div class="plain_line">When A's ip+port changes from A1 to A2, then (assuming I remember correctly)</div>
<div class="plain_line">any properly authenticated traffic from A (now A2) to B (B1) will update</div>
<div class="plain_line">B's record of A's remote endpoint to A2. Any subsequent traffic from B will be</div>
<div class="plain_line">sent to A2.</div>
<div class="plain_line"> </div>
<div class="plain_line">Note, the roaming side (one with changed ip/port) must send the first</div>
<div class="plain_line">packet, so it should be the one sending keepalive messages and it is</div>
<div class="plain_line">the side where you should set the keepalive interval (for sending</div>
<div class="plain_line">packets).</div></blockquote><div id="x85650cc1b3ab4be">Yes, and that is a solution of 50% of the cases only.</div><div id="x85650cc1b3ab4be"><br /></div><div id="x85650cc1b3ab4be"><br /></div><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div>
<blockquote type="cite" class="cite2">
<div class="plain_line"> &gt;Wireguard design and implementation is layered (which seems good).</div>
<div class="plain_line"> &gt;The secure* tunnel, including the kernel module and wg tool seem</div>
<div class="plain_line"> &gt;to be in a reasonable state, but automation, DNS, key exchange are</div>
<div class="plain_line"> &gt;out of scope for them. It is meant to be provided by tooling, which is</div>
<div class="plain_line"> &gt;currently very raw.</div>
<div class="plain_line"> </div>
<div class="plain_line"> I don't understand...</div>
<div class="plain_line"> When I am on my way in a roadwarrier scenario with my mobile, with a</div>
<div class="plain_line"> changing IP and a changing connection that works very well.</div>
<div class="plain_line"> If the IP of my Server is changing, it's not working well at all. I</div>
<div class="plain_line"> don't think that this should be declared as 'works as intended'.</div>
</blockquote>
<div class="plain_line"> </div>
<div class="plain_line">I am not saying wireguard solution is working as intended. I am saying</div>
<div class="plain_line">the DNS resolution is meant to be implemented in out-of-kernel tooling,</div></blockquote><div id="x85650cc1b3ab4be">&lt;&lt;It's a bit OT, but I actually think letting the kernel part of WireGuard</div><div id="x85650cc1b3ab4be">do the DNS queries is totally legit and a wishful (maybe optional) feature:</div><div id="x85650cc1b3ab4be">https://www.kernel.org/doc/Documentation/networking/dns_resolver.txt</div><div id="x85650cc1b3ab4be"> </div><div id="x85650cc1b3ab4be">This would allow DynDNS scenarios without any monitoring daemons running</div><div id="x85650cc1b3ab4be">and proper configuration using systemd.&gt;&gt; [Vincent Wiemann]]</div><div id="x85650cc1b3ab4be"><br /></div><br /><blockquote type="cite" class="cite2"><blockquote type="cite" class="cite2"><div class="plain_line"><br /> &gt;As a workaround you could</div>
<div class="plain_line"> &gt;   - unconditionally periodically update the endpoint</div>
<div class="plain_line"> This would break existing transfers without reason.</div>
</blockquote>
<div class="plain_line"> </div>
<div class="plain_line">As I said, you could try periodically updating the endpoint, and only</div>
<div class="plain_line">endpoint, not restarting or changing anything except peer ip+port.</div>
<div class="plain_line">If updating endpoint information (to the same or valid ip+port) does break</div>
<div class="plain_line">connections, then I believe it is a bug that should be reported.</div></blockquote><div id="x85650cc1b3ab4be"><br /></div><div id="x85650cc1b3ab4be">I was not able to find commands for updating the endpoint without restarting the tunnel.</div><div id="x85650cc1b3ab4be">Can you give me a hint?</div><br /><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div>
<div class="plain_line"> </div>
<blockquote type="cite" class="cite2">
<div class="plain_line"> &gt;   - monitor last handshake time, when large update endpoint or restart</div>
<div class="plain_line"> &gt;     tunnel</div>
<div class="plain_line"> That could be an option.</div>
<div class="plain_line"> &gt;   - add keepalive to server - it might reduce your downtime</div>
<div class="plain_line"> How would that help?</div>
</blockquote>
<div class="plain_line"> </div>
<div class="plain_line">Keepalive is one-sided. As your client doesn't know where to send</div>
<div class="plain_line">the keepalive request, it doesn't help. Keepalive on the server can.</div></blockquote>I have activated keepalive on both client and server.</div><div id="x85650cc1b3ab4be"><br /></div><div id="x85650cc1b3ab4be"><br /><blockquote type="cite" class="cite2"><div class="plain_line">If the server changes IPs and the client remains reachable on previous ip+port,</div>
<div class="plain_line">keepalive on server should keep your tunnel alive.</div>
<div class="plain_line"> </div>
<div class="plain_line"> </div>
<div class="plain_line">Roaming will work if the side that changes ips:</div>
<div class="plain_line">  a) has keepalive enabled, so it will send a packet periodically</div>
<div class="plain_line">  b) sends an unsolicited packet (e.g. requests something from the</div>
<div class="plain_line">     other side as clients usually do but server less so)</div>
<div class="plain_line">  c) ip is changed after a request is received and before a reply is</div>
<div class="plain_line">     sent (could happen but unreliable)</div>
<div class="plain_line"><br /></div></blockquote><div id="x85650cc1b3ab4be"><br /></div><div id="x85650cc1b3ab4be">I think, there is an 'or' between a, b and c?</div><div id="x85650cc1b3ab4be"><br /></div><div id="x85650cc1b3ab4be">Greetings,</div><div id="x85650cc1b3ab4be">Hendrik</div><div id="x85650cc1b3ab4be"><br /></div><div id="x85650cc1b3ab4be"><br /></div><br /><blockquote type="cite" class="cite2"><div class="plain_line"><br /></div>
</blockquote></div>
</body></html>

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

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Keep-alive does not keep the connection alive
  2019-10-17 19:03                 ` Re[2]: " Hendrik Friedel
@ 2019-10-20 20:25                   ` Ivan Labáth
  0 siblings, 0 replies; 14+ messages in thread
From: Ivan Labáth @ 2019-10-20 20:25 UTC (permalink / raw)
  To: Hendrik Friedel; +Cc: wireguard

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, back to index

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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
	public-inbox-index wireguard

Example config snippet for mirrors

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