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 (0)