WireGuard vs OpenVPN

A business setting up remote access has to pick a protocol, and the choice is usually made by whichever the firewall documentation demonstrated first.

The two mainstream options are not variations on a theme. They make opposite decisions about the same design question — how much should be configurable — and everything that follows, including their respective weaknesses, comes from that one difference.

The design difference everything follows from

OpenVPN is built on TLS and inherits its approach: cipher suites are negotiated, transport can be UDP or TCP, authentication methods are pluggable, and a great deal is configurable at both ends.

WireGuard takes the opposite position. It fixes its cryptographic primitives — Curve25519, ChaCha20 and Poly1305 — with no negotiation, encapsulates IP packets over UDP only, and offers a deliberately small set of options.

The project is explicit about why. It aims to be comprehensively reviewable by individuals, in contrast to what it calls behemoths like IPsec implementations or OpenVPN with OpenSSL, where auditing the codebase is described as an overwhelming task even for large teams of security experts.

That is a genuine security argument and it is worth taking seriously. It is also a genuine constraint, because the same rigidity that makes it small makes it inflexible in specific situations.

Where WireGuard wins clearly

Roaming

WireGuard supports full IP roaming at both ends: each side sends encrypted data to the most recent endpoint address from which it authentically decrypted data. A device moving between wifi and mobile data does not renegotiate anything — traffic simply continues from the new address.

For staff working from phones, trains and cafés this is the single most visible difference. It converts a category of user complaint — the VPN dropped when I moved — into something that does not occur.

Performance and simplicity

Running in the Linux kernel avoids copying packets between kernel and userspace, which is why WireGuard typically delivers higher throughput on the same hardware. On a firewall terminating many concurrent connections, that translates directly into capacity.

The small configuration surface is a security property as much as a convenience one. Most VPN weaknesses in practice come from misconfiguration rather than from a broken cipher, and a protocol with fewer options has fewer ways to be configured badly.

Where OpenVPN remains the right answer

Restrictive networks

WireGuard is UDP only. Hotel networks, some corporate guest wifi, and a number of countries block or heavily degrade UDP on arbitrary ports.

OpenVPN can run over TCP, including on port 443 where it is largely indistinguishable from ordinary web traffic to a simple filter. That is slower and less elegant, and it is the difference between working and not working in exactly the places staff most need remote access.

For a business with travelling staff, this single point frequently decides the choice — or produces the honest answer of running both.

Certificate-based identity at scale

OpenVPN's TLS foundation brings an established public key infrastructure model: per-user certificates, a certificate authority, and revocation through a revocation list. Where a business already runs a PKI, or needs individually revocable per-user credentials integrated with existing identity, that model fits.

WireGuard authenticates peers by public key, which is simple and effective, but the surrounding management — issuing, distributing, rotating and revoking keys across a workforce — is something you provide rather than something the protocol provides.

Crypto agility

Fixed primitives are a strength until one of them needs replacing. OpenVPN can move to a different cipher through configuration; WireGuard would require a protocol version change and a coordinated upgrade. This is a long-horizon consideration rather than a present concern, but for a system expected to run for a decade it is a real one.

Choosing

That last row is worth taking seriously rather than treating as a non-answer. Running both on the same firewall is genuinely common: WireGuard as the default because it works better for most people most of the time, with OpenVPN over TCP as the fallback for the networks where UDP does not survive.

It costs a second configuration and a second set of credentials to manage. It removes an entire category of support call, and both terminate on the same platform without additional licensing.

What the choice does not change

Being clear about this prevents the protocol decision from absorbing attention that belongs elsewhere. Neither protocol changes any of the following, and all of them cause more real problems than the protocol choice does.

• Address collisions with staff home networks, which produce failures that look like protocol faults and are not.
• Whether internal DNS resolves correctly once connected.
• Whether access is authenticated with a second factor, which matters far more than the tunnel's cipher.
• What a connected device is permitted to reach, which is a segmentation and policy question.
• Certificate or key lifecycle, and whether anything monitors expiry.

A VPN using either protocol, terminating into a flat network, with single-factor authentication and no expiry monitoring, is a weak deployment regardless of which was chosen.