← All posts

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

MetricWireGuardOpenVPN (UDP)OpenVPN (TCP)
iperf3 throughput740 Mbps310 Mbps180 Mbps
1 GB file download11.2 s26.8 s46.1 s
% of raw 1 Gbps74%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":

ProtocolMedian handshake95th percentile
WireGuard0.4 s0.7 s
OpenVPN UDP4.2 s7.8 s
OpenVPN TCP5.9 s11.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:

  1. CPU cycles spent on encryption per packet.
  2. 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:

ProtocolPing 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.