VPNSmith
self-host-vpnCOMP

WireGuard vs OpenVPN on VPS: real iperf3 benchmarks 2026

100 iperf3 runs on Contabo VPS S, Orange 1 Gbps fiber Paris → Nuremberg. WireGuard wins on throughput (-4% vs raw link) and latency (+18ms). OpenVPN: -27% throughput.

By Eric Gerard · Fondateur · VPNSmith — Spécialiste self-host VPN & VPS GDPR10 min readPhoto: Umberto — Unsplash

You're torn between WireGuard and OpenVPN for your self-hosted VPN. You've read everywhere that "WireGuard is faster" without ever seeing a verifiable number, measured on real hardware, under reproducible conditions. We spent a week benchmarking both protocols on the same Contabo VPS, from the same Orange fiber in Paris, with 100 iperf3 runs spread over 3 different time slots. Here are the raw numbers, the full methodology, and an honest verdict per use case.

Spoiler: WireGuard wins on every measurable axis, but the real delta is smaller than marketing says — and OpenVPN keeps a legitimate use in two specific scenarios.

Lab setup

For the numbers to mean anything, the environment must be locked down. Here's exactly what we used.

Server side:

  • VPS Contabo S Cloud (4 vCPU AMD EPYC, 8 GB RAM, NVMe, 600 Mbps advertised)
  • Nuremberg datacenter (DE), ASN 51167
  • Ubuntu 24.04 LTS, kernel 6.8.0-31-generic
  • WireGuard 1.0.20210914 (wireguard-tools 1.0.20210914-1ubuntu4)
  • OpenVPN 2.6.10 (official Ubuntu package)
  • MTU set to 1420 for WireGuard, 1500 for OpenVPN (recommended defaults)

Client side:

  • MacBook Pro M2 (16 GB RAM), macOS 14.5
  • Orange Pro 1 Gbps symmetrical fiber (Paris 13e)
  • Livebox 6 in bridge mode, MacBook plugged via RJ45 Ethernet into a Cisco SG250 managed switch
  • WireGuard 1.0.16 (official App Store)
  • OpenVPN Connect 3.5.0

Reference link (raw, no VPN):

  • iperf3 to the Contabo VPS, TCP: 938 Mbps down / 932 Mbps up (median over 100 runs)
  • Average RTT ping: 22 ms (Paris → Nuremberg, direct Orange/Telia route)
  • Jitter: 0.3 ms

That's the baseline. Everything below compares against these numbers.

iperf3 methodology

We wrote a bash script that loops iperf3 under this protocol:

  • 5 tested configurations: baseline (no VPN), WireGuard, OpenVPN UDP, OpenVPN TCP, OpenVPN UDP with LZO compression disabled (isolated test).
  • 3 time slots: 9am, 2pm, 9pm (Paris time) to capture backbone load variation.
  • 100 runs total per configuration: ~33 runs per slot.
  • Run duration: 30 seconds (iperf3 -t 30), with 5 seconds of warm-up ignored via -O 5.
  • Captured metrics: mean throughput, min/max throughput, TCP retransmits, client + server CPU% (via sar and top).
  • UDP test: iperf3 -u -b 1G -t 30 -O 5 to saturate the link.
  • Latency test: ping -c 1000 -i 0.2 IP_VPS in parallel with each iperf3 session, median RTT.

All sessions were launched via SSH from a third host (Raspberry Pi on the same LAN) to avoid polluting the measurement on the MacBook side. iperf3 JSON output (--json) was aggregated into a Pandas dataframe to compute medians (more robust than mean against network outliers).

Script and raw data available on request at contact@vpnsmith.com (12 MB of JSON).

Throughput results

Median over 100 runs per configuration, rounded to the Mbps:

ConfigurationDown (Mbps)Up (Mbps)Delta vs baselineTCP retransmits
Baseline (no VPN)9389320.02 %
WireGuard UDP901893-4.0 %0.03 %
OpenVPN UDP (AES-256-GCM)684678-27.1 %0.11 %
OpenVPN TCP (AES-256-GCM)412408-56.1 %1.8 %
OpenVPN UDP (ChaCha20)712706-24.2 %0.09 %

Three honest observations:

  1. WireGuard caps at 96% of the raw link. The lost 4% is protocol overhead (WireGuard header 32 bytes + UDP 8 bytes + IP 20 bytes = ~60 bytes on a 1420 MTU = ~4.2%). It's math, not implementation inefficiency.
  2. OpenVPN UDP loses ~27%. TLS protocol overhead + OpenVPN encapsulation are expensive. We replicate the Phoronix benchmarks published in 2024 (-25 to -30%).
  3. OpenVPN TCP is a trap. TCP-over-TCP causes cascading retransmits as soon as a packet drops. On a stable link (our fiber, 0.02% loss), we still hold 412 Mbps. On Wi-Fi or 4G with loss, it collapses to <100 Mbps.

ChaCha20 vs AES-256-GCM on OpenVPN: on the M2 (which has AES-NI hardware), AES wins slightly. On a Raspberry Pi 4 (no AES-NI), we retested out of curiosity: ChaCha20 is +18% vs AES. Good to know for ARM setups.

Latency results

Median RTT ping (ms) captured during the iperf3 sessions:

ConfigurationMedian RTTJitterp99
Baseline22 ms0.3 ms24 ms
WireGuard UDP40 ms0.5 ms43 ms
OpenVPN UDP51 ms1.2 ms58 ms
OpenVPN TCP67 ms4.8 ms89 ms

WireGuard adds +18 ms to the RTT (crypto overhead + kernel stack traversal). OpenVPN UDP: +29 ms. OpenVPN TCP: +45 ms with 10× higher jitter — unusable for competitive gaming or demanding VoIP.

For real usage (browsing, Netflix 4K streaming, Zoom calls): WireGuard is imperceptible. OpenVPN UDP stays smooth. OpenVPN TCP, you can feel it in real-time games.

CPU consumption

We sampled top every second during the benchmarks. Average over 30 seconds of transfer at 900 Mbps (WireGuard) or 680 Mbps (OpenVPN UDP):

ConfigurationVPS CPU (4 vCPU)MacBook M2 CPU
WireGuard UDP8 % (1 partial core)3 % (1 P-core)
OpenVPN UDP47 % (1 saturated core + spillover)28 % (1 P-core + 1 E-core)
OpenVPN TCP38 %24 %

WireGuard runs in the kernel (wireguard.ko module), which eliminates costly user/kernel context switches. OpenVPN runs in userland — every packet does a kernel → userland → kernel round trip for encryption. On a 4 vCPU VPS that's manageable. On a Raspberry Pi 4 (4 Cortex-A72 cores), OpenVPN saturates one core at 100% from 80 Mbps onward.

Practical implication: on a Contabo VPS S at €4.99/month, WireGuard leaves you 90% of CPU for other services (Bitwarden, Nextcloud, Umami). OpenVPN eats half of it when the tunnel is busy.

Long-term stability (7 days)

We ran one client of each side for 168 consecutive hours with:

  • A ping every 5 seconds to measure loss
  • A iperf3 -t 10 every hour to verify the tunnel still carries
  • Auto-reconnect logs
MetricWireGuardOpenVPN UDP
Tunnel uptime100.00 %99.87 %
Automatic reconnects09 (MTU changes + 1 DH renegotiation timeout)
Lost pings / 120,96014 (0.012 %)167 (0.138 %)
Server memory (RSS)3.2 MB28 MB

WireGuard is stateless by design (no "connection" established, just known peers). When the client switches to 4G and back to Wi-Fi, the tunnel resumes in under 200 ms without renegotiation. OpenVPN must redo a TLS handshake at each network change (~3-5 seconds).

For mobile (a phone switching Wi-Fi/4G all day): WireGuard is 20× more reactive. We checked it on iPhone walking through Paris on an RER + metro trip.

Security analysis

The security debate is often biased by "OpenVPN has existed for 20 years so it's more mature." Let's look at the facts:

WireGuard:

  • Modern crypto primitives: Curve25519 (ECDH), ChaCha20-Poly1305 (AEAD), BLAKE2s (hash), SipHash24 (hash table).
  • ~4,000 lines of C code in the kernel module.
  • Formal audit by Cure53 published in 2018 — no critical vulnerability found. Partial re-audit in 2020 by Trail of Bits on the macOS port, same result.
  • Included in the mainline Linux kernel since 5.6 (March 2020). Reviewed by Linus Torvalds and the netdev team.
  • No crypto configuration possible (by design): you use what WireGuard imposes. Impossible to configure a weak protocol by mistake.

OpenVPN:

  • Configurable primitives: default is AES-256-GCM, but you can end up with Blowfish-128 in CBC if you follow a 2015-era tutorial.
  • ~70,000 lines of C code (+ OpenSSL ~700,000 lines as a dependency).
  • OSTIF audits in 2017 and 2018 — a few bugs found and fixed, no critical RCE.
  • Attack surface ~14× larger than WireGuard (raw lines-of-code ratio, to be weighted of course).
  • Historical vulnerabilities tied to OpenSSL (Heartbleed 2014 hit OpenVPN).

Honest verdict: both are solid in 2026. WireGuard has an architectural advantage (smaller attack surface, modern primitives, can't misconfigure). OpenVPN has a maturity advantage (20 years of production, active bug bounties, code reviewed by hundreds of eyes). For a self-host, we pick WireGuard without hesitating — the simplicity/security ratio is unbeatable.

Verdict per use case

Use caseRecommendation
Personal self-host VPN (1-10 devices)WireGuard — no debate
Mobile switching Wi-Fi/4GWireGuard — near-instant handshake
Bypass corporate firewall (TCP/443 required)OpenVPN TCP on port 443
Site-to-site between two datacentersWireGuard — minimal overhead
Competitive gaming / demanding VoIPWireGuard — lower latency and jitter
Raspberry Pi / low-power ARM hardwareWireGuard — 5× less CPU
Legacy OS compat (Windows 7, old Android)OpenVPN — WireGuard clients not maintained pre-Windows 10
Anti-DPI obfuscation (Iran, China, Russia)Neither raw → wstunnel or Cloak as a wrapper

If you're starting from scratch to host your own VPN on a Contabo VPS, follow our step-by-step WireGuard guide — it's the same VPS tested here, and you copy-paste the scripts.

If you're fighting corporate or state-level DPI, look at the custom routing guide with DPI bypass which combines WireGuard with an obfuscation layer.

If you're still hesitating on the VPS provider (Contabo vs Hetzner vs OVH), we compared the three under real conditions.

Reproduce these benchmarks at home

If you want to redo these tests:

# Contabo server side
sudo apt install -y iperf3
sudo iperf3 -s -D

# Client side (Mac/Linux)
# Baseline (no VPN)
iperf3 -c IP_VPS -t 30 -O 5 --json > baseline.json

# WireGuard (tunnel active)
iperf3 -c 10.66.66.1 -t 30 -O 5 --json > wireguard.json

# OpenVPN UDP (tunnel active)
iperf3 -c 10.8.0.1 -t 30 -O 5 --json > openvpn-udp.json

Run 100 iterations with a simple for loop and compute the median via jq:

jq -s 'map(.end.sum_received.bits_per_second) | sort | .[length/2]' wireguard.json

If you get very different numbers: check the MTU (ping -M do -s 1372 IP), the quality of the Orange link (an mtr to Nuremberg must show <1% loss), and that the VPS is not in CPU steal (mpstat -P ALL 1).

Order the tested VPS

Our exact setup: Contabo VPS S Cloud 24 months (~€5.49/mo equivalent). It's the offer Eric has been using for 14 months for his personal tunnel + a Bitwarden instance + a self-hosted Umami. No degradation observed even with all three services running in parallel.

Sources

Article published 2026-06-02. Benchmarks performed between May 25 and June 1, 2026 on a Contabo VPS S Cloud (Nuremberg). Raw JSON data available on request at contact@vpnsmith.com.

Affiliate disclosure: the Contabo link above is a tracked link that pays us ~10% of the first payment if you subscribe. It doesn't change your price. We use this VPS ourselves for 14 months — if we didn't recommend it, it wouldn't be in this article.

★ Datacenter Nuremberg GDPR · ✓ IPv4 dédiée incluse · 200+ Mbps garantis

Get Contabo30 jours satisfait ou remboursé