wireguard tunnel slower than OpenVPN—what am I missing?

I've been benchmarking WireGuard against OpenVPN on a new OVHcloud KVM instance and something doesn't add up. WireGuard is consistently 40% slower in my iperf3 tests despite all the hype about kernel integration and lower virtualization tax. Setup: Debian 12, standard 1500 MTU on both ends, AES-NI available on host (EPYC 7xx2). OpenVPN with AES-256-GCM hits 650 Mbps; WireGuard with default configs struggles to break 400 Mbps. CPU usage is actually higher with WireGuard which contradicts everything I've read. Tried switching to chacha20-poly1305 explicitly, no change. Both tunnels terminate on the same VPS, same peer, same test window. Where's the overhead hiding? Is this an OpenVZ container pretending to be KVM again (I've seen that trick before), or am I missing something obvious in the kernel module behavior?

¡the problem is the MTU, I am fink! In WireGuard the packet overhead is different, the server red has a MTU too high and this causes fragmentation. I am see this before in a VPS cheap, the provider has a network old with PPPoE or similar. Try to put MTU 1420 in the interface WireGuard and test again. The virtualization tax in KVM is small, but the packets broken kill the performance. ¡Good luck!

Idk why I do this but I stayed up until 4am once chasing the exact same ghost

Turns out the provider was doing some weird vlan tagging on their upstream that dropped mtu to like 1392 without telling anyone anyway heres what I found

# wg show | grep mtu
# (nothing, obviously)
# ip link show dev wg0
# 1500, lies, all lies

Try `ping -M do -s 1472 $peer` and watch it fail

Then work backwards from there. My fix was mtu 1380 and suddenly wireguard beat openvpn by 2x. Anyway hope this helps someone else avoid my 3am suffering

Kate3 | you chase ghosts | I chase packets | cat /sys/class/net/eth0/mtu | grep 1500 | this is a lie | the provider lies | ip link set wg0 mtu 1420 | test again | grep insight | sort -u | wc -l | one problem found | sed 's/ignorance/bliss/' | this does not apply to networking | the tunnel is only as fast | as the smallest mtu | in the path | find it | or suffer |

Thanks for posting fiss! I have same problem in my server from Vultr, WireGuard was slow like turtle and I think is my fault. I change MTU to 1420 like sofialund say and now is very fast! Before I read fiss forum for months and never register, but fiss fix save me. Maybe provider should tell about MTU limit no? Is hidden problem for many people I think. I am happy now, thanks again!

CPU higher on WireGuard? That's backwards from what I'd expect.

Which EPYC 7xx2 model?

7313P. Single socket, 16 cores. And before anyone asks, no SMT pinning weirdness, no cpulimit from the host that I can detect. `lscpu` shows the full count, `cpufreq-info` says performance governor. I checked.

This is the thing though—ping with 1472 goes through clean. 1473 fragments. So path MTU to the peer is 1500, no PPPoE in sight. I already dropped wg0 to 1420 earlier today, zero difference in iperf3. Same ~400 Mbps ceiling.

The MTU theory is elegant but it doesn't fit my numbers. If fragmentation were the killer, I'd expect packet loss or at least variance in the iperf3 output. What I get is rock-steady 400 Mbps, no retransmits, just a hard wall. CPU pinned at ~70% of one core on the VPS during the test. OpenVPN same test sits at ~45% of one core and fills the pipe.

Something else is throttling WireGuard specifically.

There's your signal. WireGuard is single-threaded per tunnel. OpenVPN can spread across workers. On a 7313P with AES-NI, AES-256-GCM in OpenVPN is probably using multiple cores while WireGuard queues everything through one softirq.

Check `mpstat -P ALL 1` during the test. I bet one core is 100% in %soft, rest are idle. That's not overhead in the protocol sense, that's a throughput ceiling from the design.

Not much you can do except run multiple WireGuard peers and bond, or accept that 400 Mbps is the single-flow limit on that clock speed.

The truth | grep -v marketing | wc -l | one

Kate3 | run `perf top -a` | look for `chacha20_poly1305` | or `curve25519` | the kernel does the work | but one cpu does the kernel | this is the way | until it is not | multipath is a hack | but a working hack | ip link add bond0 type bond | no | wrong tool | mptcp | maybe | complexity is the enemy | 400 Mbps is the enemy | choose |