WireGuard vs OpenVPN Speed Comparison: The Real Numbers

Almost every wireguard vs openvpn speed comparison you will read cites the same two numbers: 1,011 Mbps against 258 Mbps. Those numbers are real, they come from the WireGuard whitepaper, and they were measured on Linux 4.6.1 against a userspace OpenVPN. Since then OpenVPN’s data channel has moved into the kernel. The gap did not vanish, but it stopped being a single number, and anyone sizing a tunnel today needs the current shape of it.

Where the famous numbers come from

The canonical benchmark is section 8 of the WireGuard whitepaper. It used iperf3 between an Intel Core i7-3820QM and an i7-5200U, over Intel 82579LM and I218LM gigabit NICs, averaged over thirty minutes:

Protocol	Cipher suite	Throughput	Ping
WireGuard	256-bit ChaCha20, 128-bit Poly1305	1,011 Mbps	0.403 ms
IPsec	256-bit AES, 128-bit GCM (AES-NI)	881 Mbps	0.508 ms
IPsec	256-bit ChaCha20, 128-bit Poly1305	825 Mbps	0.501 ms
OpenVPN	256-bit AES, HMAC-SHA2-256, UDP	258 Mbps	1.541 ms

The line most people skip is the one that explains the result. The CPU sat at 100% during the OpenVPN and IPsec throughput runs but was not fully utilised for WireGuard, which is to say WireGuard saturated a gigabit link with headroom left and OpenVPN ran out of processor first. That is a CPU result, not a protocol-efficiency result, and it is why the ping figure moved too: a userspace tunnel copies each packet across the kernel boundary and waits on the scheduler to do it.

WireGuard’s own performance page is blunt about the vintage: “These benchmarks are old, crusty, and not super well conducted.” Treat the 4x figure as a 2017 artefact, not a spec sheet.

What changed: OpenVPN moved into the kernel

Data Channel Offload moves OpenVPN’s encrypt and decrypt path out of the daemon and into a kernel module, which removes the context switches that produced the 2017 result. Netdev maintainers accepted the ovpn module on 17 April 2025, and it ships in Linux 6.16 and later.

The effect is large. IPFire shipped OpenVPN 2.7 with DCO in Core Update 202 on 26 May 2026 and reported throughput jumping “from 1 GBit/s to 10 GBit/s per tunnel with reduced jitter and less CPU utilisation due to the kernel’s better use of the hardware’s crypto acceleration.” OpenVPN Inc. claims up to 300% over non-DCO configurations, which is the conservative end of the same story.

So the correct question is no longer “which protocol is faster.” It is “is the OpenVPN side running DCO, and can it?”

The peer-reviewed result that complicates the story

A 2025 study in Computers compared OpenVPN 2.6.12 against WireGuard 1.0.20210914 across Azure and VMware (DOI 10.3390/computers14080326). The results split by environment rather than declaring a winner:

• VMware. WireGuard led on TCP throughput, 210.64 Mbps against 110.34 Mbps, and lost far less: 12.35% packet loss against 47.01%.
• Azure. Both protocols reached a similar ~280 to 290 Mbps baseline. Under simulated high latency OpenVPN pulled ahead, 120 Mbps against 60 Mbps.

That last row is the one worth sitting with. WireGuard’s advantage is largest on clean, low-RTT paths where per-packet cost dominates. On a long, lossy, high-latency path the bottleneck moves to congestion control and retransmission behaviour, and the protocol overhead stops being the limiting factor. The authors’ conclusion is that protocol choice “should be guided by deployment environment and application requirements rather than general superiority claims.”

What actually caps your throughput

In practice, the tunnel protocol is rarely the first thing to run out.

CPU and crypto acceleration. WireGuard is fixed at ChaCha20-Poly1305 with Curve25519 and BLAKE2s, with no cipher negotiation at all. ChaCha20 is fast in software, which is why WireGuard wins on hardware without AES-NI. On a modern x86 firewall with AES-NI, DCO’s AES-256-GCM path closes most of that gap.

MTU and fragmentation. A WireGuard interface defaults to 1420 against a 1500-byte Ethernet path. Get this wrong and you pay in fragmentation or blackholed large packets long before either protocol’s cipher matters. The WireGuard MTU calculator does the arithmetic, including PPPoE and IPv6 encapsulation.

Transport. OpenVPN over TCP/443 to get through a hostile middlebox stacks TCP retransmission inside TCP retransmission. Any speed comparison that runs OpenVPN over TCP is measuring the wrong thing. Compare 1194/udp against 51820/udp.

Single flow versus many. WireGuard parallelises encryption across cores per-peer, so a single iperf3 stream can understate it. Test with -P 8.

The cost of DCO

DCO is not free, and its constraints are documented. The pfSense DCO page lists them: encryption limited to AES-256-GCM, AES-128-GCM and ChaCha20-Poly1305; a TLS-based tunnel required; UDP only, with no TCP fallback; no compression; no iroute internal routing; and /30 or smaller peer-to-peer tunnel networks unsupported. Per-peer data accounting is also unreliable.

Several of those are exactly the features people chose OpenVPN for. If your deployment needs TCP/443 to escape a restrictive network, or CBC ciphers for a 2.3-era client, DCO is off and you are back on the userspace numbers. Terminating on pfSense or OPNsense makes this concrete: the DCO checkbox and the feature set it forfeits sit on the same configuration page.

Does OpenVPN DCO change the MTU math?

DCO moves OpenVPN data-channel processing into the kernel; it does not change WireGuard’s 60/80-byte fixed encapsulation overhead. It does affect the available OpenVPN tuning options: the upstream DCO documentation excludes compression and compression framing. Check compatibility before carrying a userspace configuration into DCO. Size each tunnel for its actual transport and path MTU, then compare throughput with large packets passing successfully on both sides.

Measure it on your own link

Do not take anyone’s numbers, including these. With a 10.10.0.0/24 tunnel and the server on 10.10.0.1:

iperf3 -c 10.10.0.1 -t 30              # upstream, single flow
iperf3 -c 10.10.0.1 -t 30 -R           # downstream
iperf3 -c 10.10.0.1 -t 30 -P 8         # parallel, exposes multi-core scaling
ping -c 100 10.10.0.1                  # added latency and jitter
mtr -rwzbc 100 10.10.0.1               # where loss enters the path
ping -M do -s 1372 10.10.0.1           # largest unfragmented payload
tracepath 10.10.0.1                    # path MTU discovery

Run top -H on the tunnel endpoint during the iperf3 run. If one core is pinned, crypto is your ceiling and the protocol comparison is real. If no core is busy and throughput still disappoints, the bottleneck is the WAN, the MTU, or the middlebox, and switching protocols will not fix it.

The short version

Pick WireGuard for roaming clients, low-latency paths, hardware without AES-NI, and anything where reconnect time matters: the 1-RTT Noise handshake beats a TLS negotiation every time a laptop changes networks. Pick OpenVPN with DCO when you need TLS-based certificate infrastructure, per-user PKI revocation, or an established management stack, and accept the UDP-only, no-compression constraints. Pick OpenVPN without DCO only when a specific feature forces it, and size for a few hundred Mbps per tunnel rather than a gigabit.

If you are choosing between WireGuard and a WireGuard-based overlay rather than against OpenVPN, WireGuard vs Tailscale covers that split.