WireGuard vs OpenVPN: A Real Speed Benchmark
Throughput, handshake time, battery impact, and roaming behavior — measured side-by-side on identical hardware. Where each protocol wins and loses.
By VeilTun Team
Why protocol choice dominates VPN speed
When a VPN feels slow, people blame the server location or their ISP. The biggest single factor is almost always the protocol. Encryption overhead, handshake design, and where the protocol runs (kernel vs user space) decide how much of your raw bandwidth survives the tunnel.
This article walks through the measurable differences between WireGuard and OpenVPN — the two protocols still worth comparing in 2026. L2TP/IPSec and PPTP are out of scope; they're either slower, less secure, or both.
The benchmark setup
To compare protocols fairly, the variables that aren't the protocol have to be held constant:
- Same server hardware — a single VPS, KVM virtualization, AMD EPYC, 1 Gbps uplink.
- Same client device — a single iPhone 15 Pro on a 1 Gbps fiber connection, wired ethernet via USB-C adapter to remove Wi-Fi variance.
- Same cipher class — ChaCha20-Poly1305 on both (OpenVPN supports it since 2.5).
- Same test —
iperf3 -t 60 -P 4(60 seconds, 4 parallel streams) and a curl download of a 1 GB file from a known-fast CDN.
Numbers below are representative of consistently reproduced runs, not single best-case readings.
Throughput
| Metric | WireGuard | OpenVPN (UDP) | OpenVPN (TCP) |
|---|---|---|---|
| iperf3 throughput | 740 Mbps | 310 Mbps | 180 Mbps |
| 1 GB file download | 11.2 s | 26.8 s | 46.1 s |
| % of raw 1 Gbps | 74% | 31% | 18% |
WireGuard sustains roughly 2.4× the throughput of OpenVPN UDP and 4× the throughput of OpenVPN TCP on the same hardware. The TCP penalty is structural — running TCP inside TCP (your browser's TCP traffic, tunneled through OpenVPN's TCP transport) causes the well-known TCP meltdown problem: retransmissions stack, and throughput degrades non-linearly under any packet loss.
Handshake time
Time from "tap connect" to "tunnel established and first packet flows":
| Protocol | Median handshake | 95th percentile |
|---|---|---|
| WireGuard | 0.4 s | 0.7 s |
| OpenVPN UDP | 4.2 s | 7.8 s |
| OpenVPN TCP | 5.9 s | 11.3 s |
WireGuard's handshake is a single round-trip exchange of public keys (Noise Protocol IKpsk2). OpenVPN performs a full TLS handshake plus its own control-channel negotiation — multiple round-trips before any data flows.
This matters more than it looks. On flaky cellular networks where the connection drops every few minutes, a 5-second reconnect every time you walk between cells makes the VPN feel broken. A sub-second reconnect feels invisible.
Battery impact on iPhone
Apple's Network Extension framework runs VPN protocols in a separate process. Two factors drive battery drain:
- CPU cycles spent on encryption per packet.
- How often the radio has to wake up to process tunnel keepalives.
WireGuard wins on both. ChaCha20-Poly1305 is specifically designed for software speed on ARM cores (the iPhone A-series). And WireGuard's stateless design needs no application-level keepalives — the OS handles roaming, so the radio stays asleep longer.
Measured over a 24-hour idle period with the VPN on:
- WireGuard: ~1.8% additional battery drain
- OpenVPN UDP: ~4.6% additional drain
- OpenVPN TCP: ~6.1% additional drain (constant keepalives)
For a heavy day of streaming/browsing through the VPN, expect WireGuard to cost you about an hour less of battery than OpenVPN.
Roaming (Wi-Fi → cellular)
This is where WireGuard's design shines. Because peers are identified only by public key — not by an IP+port tuple — the tunnel survives an IP address change automatically. Switch from home Wi-Fi to LTE mid-download, and the next packet just continues on the new network.
OpenVPN typically requires a full session renegotiation when the underlying IP changes. Some clients hide this with reconnection logic, but the delay (5–10 s of dead tunnel) is real and observable.
Latency
Throughput is the headline, but latency matters more for browsing feel:
| Protocol | Ping overhead vs raw |
|---|---|
| WireGuard | +1.2 ms |
| OpenVPN UDP | +3.8 ms |
| OpenVPN TCP | +12.4 ms (variable, spikes under loss) |
Sub-2 ms overhead is functionally invisible. 12 ms with spikes is the "VPN feels laggy" experience users complain about.
When OpenVPN is still appropriate
There is one scenario where OpenVPN TCP still has a place: strict network egress filters that block UDP entirely and only allow TCP/443 traffic resembling HTTPS. Some hotel networks and corporate guest Wi-Fi do this. OpenVPN over TCP/443 can sometimes get through where WireGuard's UDP cannot.
For consumer VPN use on home internet, mobile data, or typical public Wi-Fi, this is not a meaningful concern. WireGuard works.
What this means for VeilTun
VeilTun runs WireGuard exclusively. The decision wasn't ideological — it was a benchmark. We measured both. On every metric that matters to users — speed, battery, handshake time, roaming — WireGuard wins by a margin that's not close.
If you want the underlying technical detail, the WireGuard whitepaper is short, readable, and worth your time.