1. What a VPN actually is

A VPN is an encrypted tunnel between your device and a server somewhere else. Traffic that would normally travel the open internet in plain view, where your ISP, the coffee-shop Wi-Fi, and anyone in between can read its metadata and often its contents, instead travels inside that tunnel. To the outside world it looks like a single encrypted stream going to one server. What is inside, where it ultimately goes, and what it contains stays hidden until it reaches the far end and gets unwrapped.

That is the whole idea. “Virtual private network” is a literal description: a private network built virtually, on top of a public one. Two things have to happen for the tunnel to exist. First, your device and the server must agree on a shared secret without anyone watching being able to learn it. Second, every packet after that must be encrypted with that secret and authenticated so a tampered packet gets rejected. The set of rules governing both steps, the key exchange and the per-packet encryption, is the VPN protocol.

This is the part most people skip past, and it’s the part this post is about. (For a closer look at what the tunnel itself buys you, see how VPNs let you reach a machine with every port closed.) A “VPN” in the consumer sense is a service: servers in various countries, an app, a subscription. The service is just plumbing around a protocol. The protocol decides how fast the tunnel is, how hard it is to break, how well it survives your phone switching from Wi-Fi to cellular, and whether a censor can spot and block it. Two VPN services running the same protocol behave far more alike than two protocols running on the same service. So when the question is “which is better,” the honest version of that question is about the protocol, and today that comparison comes down to two names: OpenVPN and WireGuard.

Before getting to them, it helps to know what came before, because both were designed in reaction to it.

2. A short history of VPN protocols

VPN protocols got faster, simpler, and harder to break with each generation. The progression is not subtle, and knowing it explains why OpenVPN and WireGuard look the way they do.

PPTP (Point-to-Point Tunneling Protocol) arrived first, in the mid-1990s, pushed by Microsoft. It was easy to set up and built into Windows, which is why it stuck around for so long. It was also broken almost from the start. Its authentication scheme could be cracked offline, and by the 2010s recovering a PPTP session key was a matter of hours. It is the example nobody should still be using, and it survives mostly as a checkbox in legacy router firmware.

L2TP/IPsec came next as the respectable replacement. L2TP (Layer 2 Tunneling Protocol) builds the tunnel but does no encryption itself, so it’s paired with IPsec, which does. The pairing works and is genuinely secure, but it’s heavy: double encapsulation, a fixed set of UDP ports that firewalls love to block, and a reputation for being slow.

SSTP was Microsoft’s answer to the firewall problem. It wraps the tunnel in TLS over port 443, the same port as ordinary HTTPS traffic, so it slips through almost any firewall. The catch: it’s a Microsoft-controlled protocol, closed in the parts that matter, and effectively Windows-only.

IKEv2/IPsec is the modern member of the IPsec family. IKEv2 (Internet Key Exchange version 2) handles the key negotiation, IPsec carries the data, and the combination is fast and unusually good at surviving network changes, which is why it’s a common default on phones. Solid protocol. Its main weakness is the same as L2TP’s: it relies on a small set of UDP ports, so a determined firewall can shut it out.

OpenVPN appeared in 2001 and broke the pattern. It was open source from day one, not tied to any vendor, and it could run over a port indistinguishable from normal web traffic. For roughly two decades it was the default recommendation for anyone who cared about security and didn’t want to trust a closed protocol. It’s still in heavy use today.

WireGuard is the newest, merged into the Linux kernel in 2020 after years of development. It threw out almost everything about how earlier protocols were built, OpenVPN included, and started from a much smaller and more opinionated design. It’s the other half of this comparison.

IKEv2/IPsec is a fine third option and a sensible phone default, but the live debate — the one VPN providers actually give you a toggle for — is the last two on that list.

3. OpenVPN: the two-decade workhorse

OpenVPN is a mature, open-source VPN protocol built on top of TLS, the same transport-security machinery that protects HTTPS. That single design decision, reuse TLS rather than invent a new handshake, explains most of OpenVPN’s strengths and most of its weaknesses.

Because OpenVPN uses TLS, it also uses OpenSSL, the cryptographic library behind a large fraction of the encrypted internet. Setting up an OpenVPN tunnel looks a lot like setting up any TLS connection: the client and server exchange certificates, verify identity through a public-key infrastructure, negotiate which encryption algorithm to use and only then start moving data. The encryption itself is typically AES, with AES-256 the usual choice, and the connection has perfect forward secrecy, meaning session keys are ephemeral so capturing one doesn’t expose past or future sessions.

The defining trait here is cipher agility. OpenVPN doesn’t commit to one encryption algorithm. It can use anything OpenSSL offers, and the client and server negotiate the choice at connection time. Genuinely useful: when an algorithm weakens, you swap it out without touching the protocol. It’s also the source of OpenVPN’s complexity. Every option that can be negotiated is an option that can be misconfigured, and the protocol’s codebase reflects this. OpenVPN is roughly 70,000 lines of code, and the OpenSSL library it leans on is far larger again.

OpenVPN runs over either TCP or UDP, and the choice matters:

Transport	Behavior	Best for
UDP	Faster, no delivery guarantees, lower overhead	Streaming, gaming, general browsing
TCP	Slower, guarantees ordered delivery, retransmits lost packets	Restrictive networks, unreliable links

UDP is the better default for speed. TCP mode exists for a specific reason that turns out to be OpenVPN’s standout feature. A tunnel running TCP over port 443 is, on the wire, very hard to distinguish from an ordinary HTTPS request. That makes OpenVPN good at obfuscation: hiding the fact that a VPN is in use at all. On networks that block VPNs by detecting their traffic signature, OpenVPN can often get through where a more recognizable protocol can’t, and its plugin ecosystem extends this further. The cost is performance. Running TCP inside TCP means two layers of retransmission and congestion control fighting each other, a long-known problem sometimes called “TCP meltdown,” so this mode is a fallback, not the everyday setting.

OpenVPN is the configurable, battle-tested option. Twenty-plus years of audits, attacks, and patches have hardened it, and its flexibility lets it adapt to hostile networks. The same flexibility makes it heavier, slower, and harder to audit than what came next.

4. WireGuard: the minimalist newcomer

WireGuard is a VPN protocol built on the opposite philosophy: do one thing, fix every choice in advance, and keep the codebase small enough to read in an afternoon. Where OpenVPN is roughly 70,000 lines, WireGuard is about 4,000. That number is not trivia. It is the design.

WireGuard doesn’t use TLS. Its handshake is built on the Noise protocol framework, a modern, formally analyzed pattern for setting up authenticated encrypted channels. Each side has a key pair; the private key never leaves the device, the public key is shared, and the two sides perform a Curve25519 exchange to derive a shared session key. From there, every packet is encrypted and authenticated. Like OpenVPN, WireGuard has perfect forward secrecy, with session keys rotating periodically so a compromised key exposes only a narrow window.

The sharpest contrast with OpenVPN is the deliberate absence of cipher agility. WireGuard doesn’t negotiate algorithms. It ships exactly one cryptographic suite, the same for every connection: Curve25519 for key exchange, ChaCha20 for encryption, Poly1305 for authentication, BLAKE2s for hashing. You can’t pick a weaker option, you can’t misconfigure the negotiation, and there’s no negotiation step for an attacker to exploit with a downgrade attack. If one of those algorithms ever needs replacing, that happens through a versioned protocol update, not a per-connection setting. This is a real tradeoff, not a free win: it trades OpenVPN’s adaptability for simplicity and a smaller attack surface. WireGuard’s designers decided the smaller surface was worth more.

That small, fixed design buys several practical things:

• Speed. WireGuard runs over UDP exclusively and has far less per-packet overhead than a TLS-based protocol. On Linux it runs inside the kernel rather than as a userspace process, which removes a layer of copying and context-switching. The result is faster transfers and lower latency, most noticeable on high-bandwidth links.
• Silent when idle. A WireGuard endpoint sends no packets unless there’s data to move. It doesn’t announce itself. To a network observer, an idle WireGuard peer is invisible.
• Roaming without reconnects. Because a WireGuard “connection” is really just a session key tied to a peer’s public key, not a stateful socket, switching networks doesn’t tear down the tunnel. Your phone moving from Wi-Fi to cellular keeps the same session; the packets simply start arriving from a new address.

The minimalism isn’t free. WireGuard has no built-in obfuscation: its traffic is recognizable as WireGuard, so a censor that wants to block it can. And by default WireGuard assigns each client a static IP address inside the tunnel. For a corporate network that’s fine; for a privacy-focused consumer VPN it’s a problem, because a static internal address is a stable identifier that can link your sessions together over time. VPN providers that offer WireGuard generally solve this themselves, with a layer that hands out dynamic addresses and discards the mapping, but it’s solved on top of WireGuard, not by it.

5. WireGuard and OpenVPN compared

With both protocols described, here is how they compare on the dimensions that actually decide a choice. The short version: WireGuard wins on speed and auditability, OpenVPN wins on stealth and flexibility, and both are secure.

5.1. Speed

WireGuard is faster, and the reasons are structural rather than incidental. It carries less per-packet overhead, runs UDP-only so it never pays the TCP-over-TCP penalty, and on Linux executes in the kernel. OpenVPN in its fast UDP mode is no slouch and most people browsing the web would struggle to tell them apart, but on a fast connection, or on a high-latency one, or when you’re pushing large transfers, WireGuard’s lower latency and higher throughput show up clearly. For streaming and gaming, WireGuard is the better starting point.

5.2. Security and auditability

Both protocols are secure. Neither has a known break, both use strong modern encryption, and both have perfect forward secrecy. They get there differently. OpenVPN’s security rests on twenty-plus years of public scrutiny: a long, well-documented history of audits and patched vulnerabilities, which is its own kind of evidence. WireGuard’s security rests on a small attack surface: 4,000 lines is something a security team can audit completely, against OpenVPN’s 70,000 plus the much larger OpenSSL underneath. Fixed cryptography also means no downgrade attacks and no misconfiguration. This is less a winner than a difference in kind: one protocol earns trust through decades of exposure, the other through being small enough to audit completely.

5.3. Censorship resistance and obfuscation

OpenVPN wins this one outright. Its TCP-over-443 mode makes a tunnel that’s hard to distinguish from ordinary HTTPS, and its plugin ecosystem pushes that further, so on networks that actively detect and block VPNs, OpenVPN often still gets through. WireGuard has no native obfuscation; its packets are identifiable as WireGuard, and a censor who wants to block it can. If you’re connecting from a region with serious network filtering, this difference can be the entire decision.

5.4. Configurability and platform support

OpenVPN is the more flexible and more broadly compatible protocol. Cipher agility lets it adapt to specific requirements and to old systems, and its long history means it runs almost everywhere, including legacy platforms. WireGuard’s configuration surface is deliberately tiny, which is a feature for most users and a limitation for anyone who needs to tune the protocol or integrate enterprise authentication. WireGuard’s platform coverage is now broad, with clients across Windows, macOS, Linux, iOS, Android, BSD, and router firmware, but OpenVPN’s reach into older and unusual systems is still wider.

5.5. Stability and roaming

WireGuard has the edge for anything mobile. Its stateless, key-based model means switching networks doesn’t drop the tunnel, so a phone moving between Wi-Fi and cellular reconnects without a visible interruption. OpenVPN can recover from the same change, but it generally has to renegotiate, which the user notices as a brief stall. OpenVPN’s stability is proven and reliable on a steady connection; WireGuard’s is better when the connection itself keeps moving.

6. Which one should you use?

For most people, most of the time, use WireGuard. It’s faster, it roams better, its tiny codebase is a genuine security advantage, and consumer VPN providers have already solved its one real privacy weakness, the static internal IP, on your behalf. As a default, it’s the right call.

Reach for OpenVPN when you have a specific reason, and the clearest reason is censorship. If you’re on a network that actively hunts for and blocks VPN traffic, OpenVPN’s ability to disguise itself as ordinary HTTPS is a capability WireGuard simply doesn’t have. OpenVPN is also the better fit when you need fine-grained control over the cryptography, or when you’re connecting through old or unusual systems where its broader compatibility matters.

The good news is that this is rarely a permanent decision. Most consumer VPN services, having implemented both, give you a protocol toggle in the settings. Leave it on WireGuard and treat OpenVPN as the fallback: if a network blocks your connection, or you hit something WireGuard can’t do, switch. Neither protocol is a bad choice. They’re two different answers to the same problem, one optimized for speed and simplicity, the other for flexibility and stealth, and the choice comes down to knowing which of those you actually need.