[WireGuard] [PATCH] persistent keepalive: start sending immediately

Baptiste Jonglez baptiste at bitsofnetworks.org
Fri Jul 8 16:28:09 CEST 2016


On Fri, Jul 08, 2016 at 02:34:12PM +0200, Jason A. Donenfeld wrote:
> Rather than only start sending the persistent keepalive packets when the
> device first sends data, this changes it to send the packets immediately
> on `ip link set up`. This makes things generally seem more stateless,
> since the administrator does not have to manually ping the endpoint.

Yes, this is good to have, for the reasons mentioned by others (immediate
reachability in the reverse direction).

Does the first handshake occurs when the interface is up or when data is
first sent on the interface?

> Of course, if you have a lot of peers and all of them have persistent
> keepalive enabled, this could cause a lot of unwanted immediate traffic.
> On the other hand, if all of those peers are at some point going to be
> sending packets, this would happen anyway. I suppose the moral of the
> story is that persistent keepalive is a feature really just for clients
> behind NAT, not for servers, and it should be used sparingly, which is
> why we've set it off by default in the first place.

Sounds sensible.

If the large amount of "unwanted immediate traffic" when starting an
interface is really a problem, you could just randomize the delay between
keepalives (which might also help for obfuscation?).  But as you said,
keepalives don't really make sense for "servers", who would be the one
with lots of peers.

Just a random thought, though: are keepalive packets in only one direction
(client to server) enough to maintain a mapping in a NAT or stateful
firewall?  Aren't there edge cases where you would need keepalives in both
directions?

> 
> Hi list,
> 
> I haven't merged this yet, and I'm debating whether it's something we want.
> I'm open to all opinions here, so feed back would be most welcome.
> 
> Thanks,
> Jason
> 
> 
>  src/config.c | 5 ++++-
>  src/device.c | 2 ++
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/src/config.c b/src/config.c
> index 767d31a..910c31b 100644
> --- a/src/config.c
> +++ b/src/config.c
> @@ -106,8 +106,11 @@ static int set_peer(struct wireguard_device *wg, void __user *user_peer, size_t
>  	if (in_peer.persistent_keepalive_interval != (uint16_t)-1) {
>  		if (in_peer.persistent_keepalive_interval && (in_peer.persistent_keepalive_interval < 10 || in_peer.persistent_keepalive_interval > 3600))
>  			ret = -EINVAL;
> -		else
> +		else {
> +			if (!peer->persistent_keepalive_interval && in_peer.persistent_keepalive_interval && netdev_pub(wg)->flags & IFF_UP)
> +				socket_send_buffer_to_peer(peer, NULL, 0, 0);
>  			peer->persistent_keepalive_interval = in_peer.persistent_keepalive_interval;
> +		}
>  	}
>  
>  	if (netdev_pub(wg)->flags & IFF_UP)
> diff --git a/src/device.c b/src/device.c
> index 120f8c9..198368f 100644
> --- a/src/device.c
> +++ b/src/device.c
> @@ -40,6 +40,8 @@ static int open_peer(struct wireguard_peer *peer, void *data)
>  	socket_set_peer_dst(peer);
>  	timers_init_peer(peer);
>  	packet_send_queue(peer);
> +	if (peer->persistent_keepalive_interval)
> +		socket_send_buffer_to_peer(peer, NULL, 0, 0);
>  	return 0;
>  }
>  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20160708/e1d8dc22/attachment.asc>


More information about the WireGuard mailing list