WireGuard vs OpenVPN Benchmark (2026): Our Test, Open Script

Why we ran it

Every WireGuard vs OpenVPN article, ours included, quotes the same benchmark: the one in the 2017 whitepaper, measured on two laptops with Linux 4.6 and an OpenVPN that has since gained a kernel offload module. WireGuard's own site now calls those numbers “old, crusty, and not super well conducted”. We wanted a current measurement on a current kernel and a current OpenVPN, with a script anyone can rerun.

Results

Tunnel	Mbps, 1 stream	Mbps, 2 streams	Ping, ms	CPU busy, %
No tunnel (the wire itself)	19,764	25,799	0.07	91 to 100
WireGuard, ChaCha20-Poly1305	1,280	1,283	0.33 to 0.45	98 to 99
OpenVPN, AES-256-GCM, UDP	374	309	0.32 to 0.40	86 to 87
OpenVPN, ChaCha20-Poly1305, UDP	382	317	0.37 to 0.43	85 to 86
OpenVPN, AES-256-GCM, TCP	260	263	0.40 to 0.42	87

Throughput is what iperf3 received over 15 seconds; ping is the average of 30 packets through the tunnel; CPU is the whole machine's busy time during the run, both ends included. Raw data: vpn-protocol-benchmark-2026.json.

What it shows

WireGuard is 3.4 times faster than OpenVPN over UDP and 4.9 times faster than OpenVPN over TCP on the same CPU. The 2017 whitepaper found 3.9 times on real gigabit hardware; nine years and several OpenVPN releases later, the shape of the result is the same.
The cipher is not the bottleneck. OpenVPN with AES-256-GCM (hardware accelerated on this CPU) and with ChaCha20-Poly1305 came out within 3% of each other. What costs the time is moving every packet from the kernel to the OpenVPN program and back.
TCP costs OpenVPN another 30%. TCP inside TCP acknowledges and retransmits twice. It is the price of getting through networks that block UDP, and it is why TCP mode should be a fallback, not a default.
WireGuard uses every core; OpenVPN uses one. The whole-machine CPU figures (98% against 86%) show OpenVPN's single data thread saturating one core while the other sits partly idle. On a four-core machine the gap would widen.
Ping through either tunnel stays under half a millisecond on this link, so latency is not where the two differ; throughput per CPU cycle is.

Method

Machine: one OVH VPS, Ubuntu 24.04.4, Linux 6.8.0-139-generic, Intel Core (Haswell, no TSX) virtual CPU with AES-NI and AVX2, 2 vCPUs, 3 GB RAM, otherwise idle (load average 0.02 before the run).
Topology: both ends on the same host, in network namespaces connected by a veth pair, the way the WireGuard project's own harness tests. The tunnel endpoints are 10.200.0.1 and 10.200.0.2 on the virtual link.
WireGuard: the in-kernel module of Linux 6.8, ChaCha20-Poly1305, default MTU 1420.
OpenVPN: 2.6.19 from Ubuntu, OpenSSL, TLS with throwaway ECDSA P-256 certificates, data-ciphers set to one cipher per run, UDP and TCP. Data Channel Offload is compiled in but the ovpn-dco kernel module is not shipped with this kernel, so the data path ran in user space, as it does on most clients today.
Load: iperf3 3.16, 15-second runs with 1 and 2 parallel streams, server inside the namespace, client on the host, through the tunnel addresses. Ping: 30 packets at 0.2-second intervals.
CPU: the whole machine's busy share from /proc/stat, sampled before and after each iperf3 run. The script ran with nice 10; WireGuard's kernel work is not affected by that, and the machine had nothing else to do.

Limits of this test

Two ends on two shared cores: every absolute number is lower than two separate machines would give. Rerun it between two hosts on a fast link and the Mbps go up; we expect the ratios to hold.
No Data Channel Offload for OpenVPN. On a kernel that ships the module, OpenVPN's gap narrows; we will add that run when we have such a kernel.
Short runs on one machine, one day. It is one data point, published with everything needed to make more.

Reproduce it

Download vpn-protocol-benchmark.sh, install iperf3 wireguard-tools openvpn on an Ubuntu 24.04 machine, and run it as root. It takes about four minutes, writes /tmp/bench/results.jsonl, and removes everything it created. If you publish your numbers with your machine's details, write to info@ghostshield.ai and we will link to them from this page.

What GhostShield VPN runs

WireGuard with ChaCha20-Poly1305 in every app, which is why this result matters to us. The WireGuard vs OpenVPN page covers where OpenVPN still wins, and WireGuard vs IKEv2 and WireGuard vs IPsec cover the other two protocols people compare it with.

Questions people ask

Is this test fair to OpenVPN?

As fair as a current Ubuntu install allows. OpenVPN 2.6.19 ran with the same ciphers WireGuard uses (ChaCha20-Poly1305) and with AES-256-GCM on a CPU that has AES-NI, in UDP and TCP mode. What it did not have is Data Channel Offload, because the ovpn-dco kernel module is not shipped with the 6.8 kernel on Ubuntu 24.04; with DCO the gap would be smaller. That is also how most OpenVPN clients run today.

Why are both ends on the same machine?

So that the two tunnels face exactly the same CPU, kernel and software, with nothing else changing between runs. The WireGuard project’s own test harness works the same way, with network namespaces over a virtual link. The price is that the two ends share two cores, so every absolute number is lower than it would be between two machines. The ratio between the protocols is the finding.

Why is the baseline 20 Gbps?

Without a tunnel, iperf3 traffic over the virtual link is just memory copies inside the kernel, so it runs at whatever the CPU can move. It is there to show that the link itself was never the limit: every tunnel result is CPU cost, not network cost.

Why does OpenVPN show less CPU than WireGuard but run slower?

OpenVPN’s data path is a single user-space thread, so it saturates one core and leaves part of the second one idle, which the whole-machine figure shows as 86%. WireGuard’s kernel implementation spreads its work over both cores, hits 98% and moves three to four times as much data. More cores favour WireGuard further.

Does the cipher matter?

Not for OpenVPN on this CPU: AES-256-GCM with AES-NI and ChaCha20-Poly1305 landed within 3% of each other. The bottleneck is the copying of every packet between the kernel and the OpenVPN program, not the encryption. On a CPU without AES-NI, such as many phones and routers, ChaCha20 pulls ahead.

How do I reproduce it?

Download the script, run it as root on an Ubuntu 24.04 machine with iperf3, wireguard-tools and openvpn installed, and read /tmp/bench/results.jsonl four minutes later. It creates a network namespace, a virtual link, WireGuard keys and throwaway certificates, and removes all of it at the end. Publish your numbers with the machine’s details and we will link to them.

WireGuard vs OpenVPN: the 2026 benchmark

The result