[WireGuard] NAT-T Keepalives

[Guus Sliepen]

Some insights learned from tinc:

On Thu, Jul 07, 2016 at 06:33:11PM +0200, Jason A. Donenfeld wrote:

> a) The persistent keepalive does not need an active session and does
> not need to send any encrypted data. It simply is a UDP packet to the
> endpoint. The payload doesn't matter for the purpose of just keeping
> the NAT mapping alive.

Indeed.

> 1. What should the payload be? Should it be a single fixed byte? Or
> should it be a zero length UDP packet?

A zero-length UDP packet should be fine, although it might upset some
OSes or firewalls.

Another issue that tinc deals with is path MTU discovery. It combines
this with the heartbeat packets. While a zero-length UDP packets is
enough to keep a NAT mapping alive, the actual path between two peers
might change, and that also changes the path MTU. AFAIK WireGuard
doesn't care about this, but in case you (start to) do, you want to send
packets with the discovered MTU and perhaps a slightly bigger one too,
once in a while, to check whether the PMTU changed.

Discovering the PMTU between two peers and enforcing this inside the
tunnel helps prevent fragmentation of the outer UDP packets. This
improves performance and sometimes it's just necessary because there are
firewalls out there that block fragments.

> 2. What is an acceptable minimum interval? Every 5 seconds?
> 3. What is an acceptable maximum interval? 3600 seconds?
> 4. What is a good interval to show in documentation examples that will
> work for most people?

If you want to keep alive a NAT mapping, then experience tells me 10
seconds is something that works for virtually all NAT devices. Once you
start to go over 10 seconds, you will find there are those that will
drop the mappings. There are RFCs which tell you how a NAT device should
behave (RFC 4787 and 7857), but it's hard to find devices that follow
all these requirements. The recommended timeout for NAT devices is 5
minutes. I'm quite sure a 3600 second interval is useless in practice.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20160714/7e77fb9c/attachment.asc>