WireGuard vs OpenVPN: the differences that actually matter

The two protocols solve the same problem from opposite directions. OpenVPN was designed to be flexible: it negotiates what it will use, over a channel built on TLS, and it can be made to look like ordinary web traffic. WireGuard was designed to be small: it makes every choice in advance, so there is nothing to negotiate and very little code to audit.

Everything else follows from that one difference.

Size, and why it is the headline

WireGuard's reference implementation is roughly 4,000 lines. OpenVPN is around 70,000 lines of its own code, and it does not work without a TLS library — OpenSSL is several hundred thousand lines more. The WireGuard paper makes the argument plainly: a codebase small enough for one person to read in an afternoon is a codebase whose security properties can actually be reasoned about.

That is not a claim that OpenVPN is insecure. It has been deployed for two decades and reviewed heavily. It is a claim about how much has to be trusted, and by how many people.

Cryptography: chosen versus negotiated

	WireGuard	OpenVPN
Cipher	ChaCha20-Poly1305, fixed	AES-256-GCM or ChaCha20-Poly1305, negotiated
Key exchange	Curve25519	TLS with X.509 certificates
Hashing	BLAKE2s	SHA-2 family
Handshake framework	Noise (Noise_IKpsk2)	TLS 1.2 or 1.3
Identity	A public key per peer	A certificate per client
Cipher agility	None, by design	Yes

WireGuard's suite is not configurable. If one of its primitives is ever broken, the answer is a new protocol version rather than a config change. That sounds fragile and is deliberate: cipher negotiation is where a long list of real TLS vulnerabilities lived, because an attacker who can influence the negotiation can often talk both ends down to something weaker.

OpenVPN's certificate model is the other side of the same trade. Certificates are heavier than a 32-byte public key, but they bring revocation, expiry and a chain of trust — which is why almost every corporate deployment is OpenVPN or IPsec rather than WireGuard.

Speed

WireGuard is faster in practice, for three compounding reasons: it runs in the Linux kernel rather than in userspace, so packets are not copied across that boundary twice; ChaCha20-Poly1305 is fast on CPUs without AES hardware acceleration, which is most phones and most cheap routers; and its per-packet overhead is smaller.

The honest framing is that the gap is smaller than benchmark headlines suggest on a modern desktop with AES-NI, and larger than they suggest on a phone or a router. OpenVPN 2.6's data channel offload closed a meaningful part of it by moving the data path into a kernel module.

The number that matters is your own. Run our speed test once with the tunnel down and once with it up; the difference is what your hardware, on your line, actually pays.

Reconnection and roaming

This is the difference people feel daily and rarely name.

WireGuard is stateless between packets. There is no session to lose, so when you walk out of Wi-Fi and onto mobile data, the first packet from the new address simply updates the server's record of where that peer is. Nothing reconnects because nothing disconnected.

OpenVPN maintains a TLS session. Change network and that session has to be torn down and rebuilt, which is the two-to-ten-second pause you see when a phone switches networks with OpenVPN running.

Transport, and who can block you

OpenVPN speaks UDP or TCP. In TCP mode on port 443 it is genuinely hard to distinguish from HTTPS without deep packet inspection, which is why it survives on restrictive networks where nothing else does. TCP-over-TCP is bad for throughput — two congestion controllers fighting each other — but a slow connection beats none.

WireGuard is UDP only, with no fallback and no obfuscation in the protocol itself. A network that blocks UDP, or that fingerprints the handshake, blocks WireGuard completely. Providers work around this with a separate obfuscation layer wrapped around the tunnel, which is an addition rather than part of the protocol.

The privacy caveat worth knowing

WireGuard assigns each peer a fixed tunnel IP address and the server has to keep the peer's public key and last known endpoint in memory to route to it. The project documents this in its known limitations. A naive deployment therefore holds a longer-lived association between a user and an address than a typical OpenVPN setup does.

It is solvable — rotating peers, short-lived keys, keeping the association in memory only — but it is a thing an operator has to solve rather than something the protocol handles for you. When a provider says it runs WireGuard, this is the question worth asking it.

Which to pick

If you want	Pick
Best speed on a phone, tablet or TV	WireGuard
Instant reconnection when the network changes	WireGuard
Lowest battery cost	WireGuard
To get through a restrictive network on port 443	OpenVPN over TCP
Certificate-based identity, revocation, expiry	OpenVPN
To run it on a router with a weak CPU	WireGuard

For a consumer VPN on modern devices, WireGuard is the better default on every axis except censorship resistance, which is why VPNmine's clients use it and why the Linux setup guide is written around wg-quick. Keep OpenVPN in mind as the fallback for networks that block UDP outright.

What neither of them does

Neither protocol makes you anonymous, and neither protects you from anything that happens above the tunnel. Both encrypt the path between your device and the server, and that is the whole of what they promise. A site you log in to knows who you are either way, and the provider at the far end sees the traffic leaving its network under either protocol. Picking between them is a performance and compatibility decision, not a privacy one.