Linux kernel WireGuard can go 'fast' on decent hardware

June 16, 2025

I'm used to thinking of encryption as a slow thing that can't deliver anywhere near to network saturation, even on basic gigabit Ethernet connections. This is broadly the experience we see with our current VPN servers, which struggle to turn in more than relatively anemic bandwidth with OpenVPN and L2TP, and so for a long time I assumed it would also be our experience with WireGuard if we tried to put anything serious behind it. I'd seen the 2023 Tailscale blog post about this but discounted it as something we were unlikely to see; as their kernel throughput on powerful sounding AWS nodes was anemic by 10G standards, so I assumed our likely less powerful servers wouldn't even get 1G rates.

Today, for reasons beyond the scope of this entry, I wound up wondering how fast we could make WireGuard go. So I grabbed a couple of spare servers we had with reasonably modern CPUs (by our limited standards), put our standard Ubuntu 24.04 on them, and took a quick look to see how fast I could make them go over 1G networking. To my surprise, the answer is that WireGuard can saturate that 1G network with no particularly special tuning, and the system CPU usage is relatively low (4.5% on the client iperf3 side, 8% on the server iperf3 side; each server has a single Xeon E-2226G). The low usage suggests that we could push well over 1G of WireGuard bandwidth through a 10G link, which means that I'm going to set one up for testing at some point.

While the Xeon E-2226G is not a particularly impressive CPU, it's better than the CPUs our NFS fileservers have (the current hardware has Xeon Silver 4410Ys). But I suspect that we could sustain over 1G of WireGuard bandwidth even on them, if we wanted to terminate WireGuard on the fileservers instead of on a 'gateway' machine with a fast CPU (and a 10G link).

More broadly, I probably need to reset my assumptions about the relative speed of encryption as compared to network speeds. These days I suspect a lot of encryption methods can saturate a 1G network link, at least in theory, since I don't think WireGuard is exceptionally good in this respect (as I understand it, encryption speed wasn't particularly a design goal; it was designed to be secure first). Actual implementations may vary for various reasons so perhaps our VPN servers need some tuneups.

(The actual bandwidth achieved inside WireGuard is less than the 1G data rate because simply being encrypted adds some overhead. This is also something I'm going to have to remember when doing future testing; if I want to see how fast WireGuard is driving the underlying networking, I should look at the underlying networking data rate, not necessarily WireGuard's rate.)


Comments on this page:

From 193.219.181.219 at 2025-06-17 10:57:43:

which struggle to turn in more than relatively anemic bandwidth with OpenVPN

I'm curious whether the new OpenVPN-DCO driver is going to change that significantly. (It was merged sometime last month.) Allegedly it allows multi core processing due to moving it out of the userspace tun handler process.

By antiphase at 2025-06-17 12:50:28:

Serving L2TP on Linux is very poor in my experience because all the well-known implementations are single-threaded and when you've saturated that single core, you're out of luck for further clients/throughput, so the bottleneck isn't IPsec in traditional deployments anyway.

I guess it's an uncommon enough use case that no-one has written a new l2tpd since multi-core systems became ubiquitous.

Written on 16 June 2025.
« My views on the choice of name for SMTP senders to use in TLS SNI
A performance mystery with Linux WireGuard on 10G Ethernet »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Mon Jun 16 22:19:19 2025
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.