Loading
Cybersecurity2026-07-27· 10 min read
“3x faster” is not
what the data says.
Search this comparison and you'll get a dozen unsourced multipliers. Here's what a real, methodology-disclosed benchmark measured instead.
Max-Packet UDP Gap
0.0%
WireGuard vs OpenVPN AES-GCM, cited
Connection Setup
0x
Faster: WireGuard-C vs OpenVPN (PSK)
Small-Packet Gap
0%
Faster: WireGuard-Go vs OpenVPN, 64B
Cited Study
2020
University of Amsterdam, disclosed methodology
← Back to Global Tech SearchEvery number I found first
The headline “WireGuard wins”
64-byte packets punish
Two orders of magnitude,
Pick by workload shape,
The Problem With This Comparison, As Currently Written
Every number I found first
traced back to nothing.
Searching “WireGuard vs OpenVPN benchmark” surfaces a wall of 2026-dated posts claiming WireGuard is anywhere from 2x to 9x faster, on domains that read like content mills rather than anyone's actual test lab. None of them disclose hardware, test duration, or methodology, and the numbers contradict each other by an order of magnitude. I'm not repeating any of them. Instead, this post is built entirely on a published University of Amsterdam System and Network Engineering research paper by Erik Dekker and Patrick Spaans, which measured WireGuard-C, WireGuard-Go, OpenVPN, and strongSwan against each other in a controlled 1 Gbit/s lab, with hardware, cipher suites, packet sizes, and tooling (iPerf, mpstat, tcpdump) all disclosed in the paper itself.
It's from 2020, which I'm stating upfront rather than hiding — but the results that matter most here are architecture-driven (how each protocol handles connection setup and small-packet CPU load), and neither protocol has changed its fundamental design since. The absolute Mbit/s ceiling on 2026 hardware will be higher across the board; the relative gaps between implementations are the part worth trusting.
At Max Packet Size, It's Nearly A Tie
The headline “WireGuard wins”
claim doesn't hold here.
With maximum-size UDP packets — the case closest to bulk file transfer or video — OpenVPN's AES-256-GCM cipher reached 922 Mbit/s against a 956 Mbit/s unencrypted baseline. WireGuard-C reached 916 Mbit/s, essentially the same result within the paper's reported measurement variance. OpenVPN's older AES-256-CBC cipher was the real laggard at 824 Mbit/s — the gap in this test is more about which OpenVPN cipher you pick than WireGuard vs OpenVPN as a category.
UDP Goodput, Maximum Packet Size
Cited: Dekker & Spaans, University of Amsterdam, 1 Gbit/s lab
Small Packets Are Where The Real Gap Shows
64-byte packets punish
OpenVPN's design hardest.
Small-packet traffic — VoIP, gaming, DNS, most interactive traffic — stresses per-packet CPU overhead rather than raw bandwidth. Here the unencrypted baseline reached 209 Mbit/s; OpenVPN's best cipher (AES-256-GCM) managed only 48 Mbit/s while consuming 308% CPU on the paper's quad-core test client. WireGuard-Go reached 59 Mbit/s at 556% CPU — still CPU-hungry in absolute terms, but ahead of OpenVPN on throughput at this packet size. strongSwan's AES-GCM cipher actually led this specific test at 116 Mbit/s, which the paper attributes to its kernel-level IPsec implementation.
UDP Goodput, 64-Byte Packets
Cited: Dekker & Spaans, University of Amsterdam, 1 Gbit/s lab
Where WireGuard's Advantage Is Not Debatable
Two orders of magnitude,
not a marketing multiplier.
This is the metric where the gap is genuinely enormous and not a rounding artifact. WireGuard-C completed its total connection initiation — handshake plus setup — in a mean of 6.9 milliseconds, of which only 0.7ms was the cryptographic handshake itself. OpenVPN using certificates took 1,153.7ms on average; even OpenVPN's faster pre-shared-key mode still took 954.9ms. That's WireGuard establishing a tunnel roughly 138-165x faster than OpenVPN in this test, driven directly by design: WireGuard's three-message Noise handshake with no certificate validation versus OpenVPN's full TLS handshake. For anything that tears down and re-establishes tunnels frequently — roaming clients, ephemeral connections, ad hoc mesh setups — this is the number that actually matters, far more than steady-state throughput.
Total Connection Initiation Time (log scale)
Cited: Dekker & Spaans, University of Amsterdam — lower is faster
What This Actually Means For Picking One
Pick by workload shape,
not by hype.
If your use case is a always-on site-to-site tunnel moving bulk traffic, the cited data says the two protocols are close enough that OpenVPN's broader compatibility (TCP fallback through restrictive firewalls, mature certificate infrastructure) can be the deciding factor instead of raw speed. If your use case involves frequent reconnects, mobile/roaming clients, or a fleet of ephemeral nodes — the profile of a lot of self-hosted homelab and small-team setups, including the kind of $5-6/mo VPS I benchmarked in my Hetzner/DigitalOcean/Vultr comparison— WireGuard's connection-setup advantage and smaller attack surface (roughly 4,000 lines of code, a fixed ChaCha20-Poly1305 cipher suite with no misconfigurable options, per WireGuard's own project documentation) make it the more defensible default.
The honest version of this comparison is less dramatic than the marketing version, and that's the point — a genuinely sourced “it depends, and here's exactly what it depends on” is more useful than a confident multiplier nobody can trace back to a test.
Written by Abhishek Kushwaha
Founder and writer at Global Tech Search, based in Kathmandu, Nepal. Covers AI, infrastructure, markets, and climate with sourced data and original analysis. More about the author →
Recommended Tools
Affiliate disclosure — we may earn a commission at no cost to you.
Sources
- Erik Dekker & Patrick Spaans, Performance comparison of VPN implementations WireGuard, strongSwan, and OpenVPN in a 1 Gbit/s environment, University of Amsterdam System and Network Engineering research project (2019-2020) — all goodput, CPU, and connection-initiation figures in this post
- wireguard.com, official project site — cryptographic primitives (Noise protocol framework, ChaCha20, Poly1305, Curve25519, BLAKE2) and codebase-size claims
Every quantitative figure in this post traces to the cited 2019-2020 University of Amsterdam study, which discloses its lab hardware, VPN versions, and test methodology in full. This site did not run its own VPN throughput benchmark for this post. Numbers should be read as relative comparisons under that paper's specific test conditions, not as guaranteed absolute performance on any other network or hardware.
Global Tech Search
Trace the number, or don't repeat it.
More independent, cited breakdowns of the infrastructure decisions that actually matter.
Back to Dashboard →