TL;DR
WireGuard vs OpenVPN UDP/TCP on a typical 1 Gbps VPS — figures consistent with widely-reported public iperf3 benchmarks (e.g. Phoronix):
| Protocol | Throughput | Latency | CPU | Handshake |
|---|---|---|---|---|
| Raw link (baseline) | ~1000 Mbps | 16 ms | 0% | — |
| WireGuard | ~960 Mbps | +18 ms | ~12% | ~38 ms |
| OpenVPN UDP | ~730 Mbps | +32 ms | ~68% | ~210 ms |
| OpenVPN TCP | ~412 Mbps | +52 ms | ~78% | ~260 ms |
Full breakdown: VPNSmith — WireGuard vs OpenVPN on a VPS.
Reference environment
- VPS: Contabo VPS S class (4 vCPU, 8 GB RAM, Ubuntu 22.04)
- Client: 1 Gbps fibre (baseline ~1000 Mbps)
- Kernel: Linux 6.x
- Tools: iperf3, wireguard-tools, openvpn 2.6.x
These are indicative figures for this class of setup; your exact numbers depend on the VPS, route and time of day.
Why WireGuard wins on throughput
1. WireGuard caps at ~96% of the raw link. The lost ~4% is protocol overhead: 32-byte WireGuard header + 8-byte UDP + 20-byte IP on a 1420 MTU = ~4.2%. Math, not implementation inefficiency.
2. OpenVPN UDP loses ~27%. TLS protocol overhead + OpenVPN encapsulation are expensive. This matches Phoronix 2024 benchmarks (-25 to -30% across similar setups).
3. OpenVPN TCP is a trap. TCP-over-TCP causes cascading retransmits as soon as a packet drops. On stable fibre (very low loss) it still holds ~412 Mbps, but on Wi-Fi or 4G with even moderate loss it can collapse below 100 Mbps.
Why WireGuard wins on CPU
WireGuard runs in kernel space (Linux 5.6+). OpenVPN runs in userspace with TLS encryption — every packet involves a context switch.
WireGuard kernel: packet -> kernel crypto -> wire
OpenVPN userspace: packet -> userspace TLS -> kernel -> wire (3 context switches)
On a 1 Gbps link, that is the difference between ~12% CPU (WireGuard) and ~68% CPU (OpenVPN UDP).
Why WireGuard wins on handshake
| Protocol | Handshake | Why |
|---|---|---|
| WireGuard | ~38 ms | Single round-trip (1-RTT), Noise IK pattern |
| OpenVPN UDP | ~210 ms | TLS handshake (4 round-trips minimum) + OpenVPN negotiation |
| OpenVPN TCP | ~260 ms | TLS over TCP + an extra TCP 3-way handshake |
The faster handshake matters for short-lived connections (mobile networks, captive-portal probes, app cold-starts).
What WireGuard cannot do
Three legitimate reasons to still use OpenVPN:
- TCP-only environments. Some corporate firewalls block UDP entirely. WireGuard is UDP-native; wstunnel-style TCP wrapping is possible but complex.
- Port 443 obfuscation. OpenVPN can be configured on TCP/443 to look like HTTPS. WireGuard cannot natively.
- Audit conservatism. OpenVPN has been audited for 20+ years. WireGuard's audits (Cure53 2018, Trail of Bits 2020) are solid but younger.
For everything else (self-hosted personal VPN, server-to-server tunnels, mobile clients) WireGuard is the modern default.
Security comparison
| Aspect | WireGuard | OpenVPN |
|---|---|---|
| Cipher | ChaCha20-Poly1305 | AES-GCM (configurable) |
| Key exchange | Curve25519 | RSA/ECDH (configurable) |
| Hash | BLAKE2s | SHA-256 |
| Code size | ~4k lines C | ~70k lines C |
| Audit history | Cure53 2018, Trail of Bits 2020 | Multiple 2004-2024 |
WireGuard's smaller attack surface (far less code than OpenVPN) is its strongest security argument.
Reproduce it yourself
You don't need to take anyone's word for it: run iperf3 across a WireGuard tunnel and an OpenVPN tunnel on your own VPS, loop it a few dozen times across different hours, and keep the median. A simple for loop + jq is enough. Exact software versions and example configs are in the full write-up.
Verdict
For a self-hosted VPN on a VPS in 2026: WireGuard, unless you have a specific reason for OpenVPN. The performance gap (throughput, CPU, handshake) is too large to ignore.
If you want a step-by-step Contabo + WireGuard setup, VPNSmith has the full tutorial.
Read the full comparison: vpnsmith.com/en/blog/wireguard-vs-openvpn-vps-benchmarks-2026
Top comments (1)
Nice writeup, and matches what I've seen on my own boxes — the kernel-space vs userspace CPU gap especially. What surprised me when I first benchmarked this myself was how much the handshake latency matters in practice, not just throughput. On flaky mobile connections the 1-RTT handshake is honestly the bigger UX win over OpenVPN's multi-RTT dance, even more than the raw Mbps numbers.
One thing I'd add from the "why WireGuard wins" side: the performance case is solid, but the actual adoption blocker for a lot of self-hosters isn't throughput, it's config management once you're past 3-4 peers — who has which key, what they're allowed to reach, revoking cleanly when someone leaves. WireGuard gives you zero opinion on that by design, which is great for the protocol but means everyone reinvents it.
Worth noting too: Tailscale/Headscale and NetBird route traffic through their own userspace agent for NAT traversal, ACLs, etc. — even where the crypto itself uses kernel WireGuard, there's still an extra process in the path. A management layer that just drives stock wg-quick skips that hop, since peers run plain WireGuard. Not huge at homelab bandwidths, but it shows up at higher throughput/pps.
Curious if you've run into that in your own setup, or if you're mostly single-user/point-to-point.