wireguard tunnel slower than OpenVPN—what am I missing?

Same CPU generation I have in a Vultr bare metal in São Paulo. I see 890 Mbps WireGuard single flow no problem, but that's bare metal, not KVM. The virtualization layer matters more than people think.

OVHcloud KVM uses what, qemu with virtio-net? Check if vhost-net is actually enabled on the host side. Without it, every packet traps to qemu. WireGuard's smaller packets = more traps = more overhead. OpenVPN's larger frames amortize the same trap cost.

You won't see this in CPU usage inside the guest. It shows as host time you can't account for.

How would I check that from inside the guest? `ethtool -k eth0` shows tx-checksum-ip-generic: on, tx-tcp-segmentation: on, so virtio features are negotiated. But that doesn't prove vhost-net, just virtio.

You called it. Core 3, %soft at 98.7, others idle. Single-threaded confirmed.

So the real comparison isn't "WireGuard vs OpenVPN" it's "WireGuard single flow vs OpenVPN multi-worker on AES-NI." The hype about WireGuard being faster assumes modern CPUs and parallel workloads, or at least a use case where 400 Mbps is enough. For a single iperf3 stream, OpenVPN wins on this hardware.

Or assumes UDP bulk transfer without the OpenVPN framing overhead, which is real but irrelevant once you hit the single-core crypto ceiling. I spent a year at a CDN measuring this exact thing. Below ~500 Mbps single flow, the protocol differences matter. Above that, it's all about how many cores you can use.

WireGuard's kernel path is shorter per packet, yes. But "shorter" doesn't beat "parallel" at these throughputs. The marketing elides this completely.

For what it's worth, Cloudflare's public WireGuard benchmark numbers are from a server with 64 flows. Single flow was never their target.

This is the thing that should be in bold on every tutorial. I felt so stupid at 4am because I was testing like kate3, one iperf3, crying into my tea

Real world I have 20-30 devices behind my WireGuard, all doing their own thing. Never seen the single flow wall. But if you're building a point-to-point pipe for rsync or whatever, you feel it hard

Also re: vhost-net, you can kind of infer it from `cat /proc/interrupts` and seeing virtio0-input on a specific CPU vs spread. Not definitive but suggestive.

I work at local ISP and we test CPE with iperf3. Single flow vs multi flow is first thing we teach new tech. I am surprise this not more known in VPS forum.

For member who want test WireGuard fairly, use `-P 4` or `-P 8` in iperf3. This is not same as real multi device but show if tunnel can do more when not single thread limit.

I test my own Vultr in Singapore, single flow 320 Mbps, 8 flow 1.1 Gbps. Same tunnel, same time.

Following. I have OVHcloud in Warsaw and never test more than one flow. Now I am curious what I really get.

This. A thousand times this. I've been running tunnels since 9600 baud was fast. Every generation has this moment where the new shiny thing is "faster" until you hit the implementation detail nobody talks about.

PPP over dial-up: "compression makes it faster!" No, the 16550A FIFO is 16 bytes and you're CPU bound.
OpenVPN over early AES-NI: "hardware crypto!" No, one core at 2 GHz.
WireGuard now: "kernel path!" No, one core at whatever.

The pattern repeats. The protocol isn't slow. The test is wrong for the claim being checked.

Well. 8 flows, 1.04 Gbps. Same tunnel, same everything. I feel simultaneously relieved and foolish.

So the answer to "what am I missing" is: nothing is wrong, I was measuring the wrong thing for my assumption. WireGuard isn't slower. Single-threaded WireGuard on a single flow is slower than multi-threaded OpenVPN on a single flow, because OpenVPN spawns workers and WireGuard doesn't. For my actual use case—multiple site-to-site peers—this will never matter.

Still annoyed that none of the "WireGuard is 3x faster" articles mention this caveat. Would have saved me six hours.

Thanks all. Especially kenji3 for the mpstat nudge and tallinnying for making me feel less alone in the 4am debugging club.

This thread is gold. I was about to post the exact same "WireGuard slow" question on my Hetzner instance. Searching first actually worked for once.