The most talked-about feature to make it into the Linux kernel in recent years is called WireGuard. If you use Linux, I’m sure you must have read something about it. If not, here’s what it’s officially described as:

… a secure network tunnel, operating at layer 3, implemented as a kernel virtual network interface for Linux, which aims to replace both IPsec for most use cases, as well as popular user space and/or TLS-based solutions like OpenVPN, while being more secure, more performant, and easier to use. The virtual tunnel interface is based on a proposed fundamental principle of secure tunnels: an association between a peer public key and a tunnel source IP address. It uses a single round trip key exchange, based on NoiseIK, and handles all session creation transparently to the user using a novel timer state machine mechanism. Short pre-shared static keys — Curve25519 points — are used for mutual authentication in the style of OpenSSH.

In simpler terms, that’s just saying it’s a virtual private network (VPN) application that’s as easy to configure and use as OpenSSH, and can take the place of IPSEC for most use cases. The Internet is full of recent articles that sing its praises. However, not everybody is a fan.

For example, Michael Tremer of IPFire wrote what amounts to a rant about what’s not-so-great about the application. Regarding the benchmark published in the WireGuard whitepaper, for example, he wrote that:

The whitepaper benchmarks WireGuard. Although it is not a scientific paper, I would still expect a scientific approach to a benchmark. It is worthless if it cannot be repeated and it is worthless when it does not examine the software in a realistic lab setup.

In the Linux implementation, WireGuard is gaining an advantage by using GSO – Generic Segmentation Offloading. It creates a huge packet of 64 kilobytes and encrypts or decrypts it in one go. That way, overhead of initialising and calling cryptographic operations is being saved. If you want to maximise throughput that is a good idea to do.

However, things are again not so easy in reality. Sending such a large packet to the network adapter will require that it is being cut into many smaller packets. Usually of 1500 bytes. 64 kilobytes would result in 45 packets (1480 bytes payload and 20 bytes IP header per packet). Those will then block the adapter for quite some time, because they all will be sent in one go. Packets that should be prioritised like VoIP calls will have to wait.

So the high throughput that WireGuard claims to achieve is being bought by making other applications slower. This needs to go and the WireGuard team has already acknowledged it.

You may read other things the author rants about WireGuard here.