Practitioner comparison, grounded in running WireGuard as the egress layer of a hardened Linux workstation (the ironveil project). Architecture rationale only — no endpoints, addresses or peer configurations are reproduced here.
The WireGuard-vs-OpenVPN question is usually answered with a throughput benchmark, which is the least interesting difference between them. The differences that matter in practice are auditability, failure behaviour, and what the configuration model forces you to get right. Having run both — and settled on WireGuard for full-tunnel egress on my own infrastructure — here is the comparison I actually use.
Attack surface: ~4,000 lines vs an ecosystem
WireGuard's kernel implementation is on the order of 4,000 lines of code. OpenVPN is roughly 70,000 lines plus OpenSSL, which is several hundred thousand more and carries one of the most storied CVE histories in infrastructure software. This is not a stylistic point: code volume is attack surface, and it is review surface. WireGuard is small enough that one person can genuinely read it; its protocol (built on the Noise framework) has been formally verified. OpenVPN is not insecure — it is well-maintained and battle-tested — but nobody audits their whole OpenVPN+OpenSSL stack, and everybody could audit their WireGuard.
Cryptography: no negotiation, no downgrade
OpenVPN negotiates: TLS handshakes, configurable ciphers, modes and digests. Flexibility reads as a feature and operates as a liability — every configurable cipher is a way to configure it badly, and protocol negotiation is historically where downgrade attacks live. WireGuard refuses to negotiate. The suite is fixed (Curve25519, ChaCha20-Poly1305, BLAKE2s), and if the suite is ever broken the answer is a new protocol version, not a config change. You cannot misconfigure WireGuard's cryptography because there is nothing to configure. For an operator, deleting an entire class of mistakes is worth more than a benchmark win.
Behaviour on the wire
Three operational properties follow from the protocol design:
- Silence. A WireGuard interface does not respond to packets that fail authentication — no handshake banner, no error, nothing to port-scan. An unsolicited probe of a WireGuard port learns nothing is there.
- Roaming. Peers are identified by key, not by source address, so moving between networks (Wi-Fi to cellular, suspend/resume) re-establishes transparently in a round trip. OpenVPN reconnects are a full TLS renegotiation and you feel them.
- Kernel residence. WireGuard runs in-kernel; packets do not round-trip to a userspace daemon per packet the way OpenVPN's model requires. That, not cryptographic speed, is where most of the latency and throughput difference comes from.
Where OpenVPN still wins
An honest comparison has this section. OpenVPN over TCP/443 traverses hostile and over-filtered networks that flatly drop unfamiliar UDP — WireGuard is UDP-only, and on networks like that it simply does not connect without an obfuscation layer. OpenVPN's mature PKI model (per-user certificates, revocation, user/pass+cert combinations) maps cleanly onto enterprise access-control requirements, where WireGuard's flat static-key model needs surrounding tooling. And two decades of enterprise deployment means OpenVPN integration exists for everything. For a roadwarrior fleet behind corporate middleboxes, OpenVPN remains a defensible default; the trade-off is carrying the larger stack.
The routing model is the architecture
The under-appreciated WireGuard concept is cryptokey routing: each peer's AllowedIPs is simultaneously an ACL (which source addresses are accepted from this peer) and a routing table (which destinations are sent to it). Routing policy and cryptographic identity are the same statement. Set AllowedIPs = 0.0.0.0/0, ::/0 and the tunnel is the default route for everything — full-tunnel egress in one line.
On my own deployment that produces a deliberately simple architecture: a small set of named tunnels (the interface name encodes the exit region, replacing the anonymous wg0 convention — at 2 a.m., which tunnel is up should be answerable from the interface name), managed as first-class NetworkManager connections with manual activation — a tunnel coming up should be an operator decision, not a race at boot. While a tunnel is up, full-tunnel AllowedIPs makes it the only route out.
One honest caveat belongs here, because VPN marketing routinely gets it wrong: full-tunnel routing is a route-based kill-switch, which is an implicit one. If the interface drops, the routes drop with it, and traffic can in principle egress over the underlying interface until the tunnel returns. A genuine fail-closed posture needs an explicit firewall rule — "nothing leaves except via the tunnel interface" — independent of routing state. Knowing which of the two you are running matters more than which VPN protocol you chose; on my own build the hard fail-closed rule is documented as planned work rather than claimed as present.
DNS has to follow the tunnel
The most common leak in any VPN architecture is not the tunnel — it is DNS quietly egressing in plaintext on the underlying interface. The fix is architectural: resolve through a local filtering resolver whose upstream is already encrypted (DNS-over-HTTPS), so queries leave the host as TLS and then ride the tunnel like all other traffic. An observer on the external interface sees only tunnel-encrypted packets; the upstream resolver sees the tunnel's exit address, never the host's, and never a plaintext query. Whichever VPN you run, if you have not traced where your DNS physically exits, the comparison above is moot.
The decision, in one table
| WireGuard | OpenVPN | |
|---|---|---|
| Codebase / audit surface | ~4k LoC, formally verified protocol | ~70k LoC + OpenSSL |
| Crypto agility | None — fixed modern suite (a feature) | Negotiated — flexible, misconfigurable |
| Hostile-network traversal | UDP only — struggles under DPI | TCP/443 mode — excellent |
| Roaming / reconnect | Native, near-instant | Full renegotiation |
| Enterprise PKI / revocation | Needs surrounding tooling | Mature, built-in |
| Unsolicited-probe response | Silent | Identifiable service |
For self-managed infrastructure where you control both ends, WireGuard is the right default: the protocol's simplicity is a security property, and cryptokey routing makes the intended architecture explicit. Choose OpenVPN when the network between the ends is the adversary, or when enterprise identity machinery has to live inside the VPN itself. The full deployment context — tunnel management, DNS chain and the fail-closed caveat — is documented in the ironveil project.