WireGuard vs OpenVPN vs IKEv2: A Plain-English VPN Protocol Comparison

The protocol your VPN uses decides how fast it is, whether it survives a subway tunnel, whether a censorship firewall can spot and block it, and how much code a security researcher has to audit before trusting it. Most apps default to WireGuard today and let you switch in a settings menu most people never open. That default is right most of the time—but not always.

This guide skips the generic pros-and-cons grid. Instead it works backward from what you are actually doing—switching between Wi-Fi and cellular, getting around a restrictive network, streaming, gaming, or connecting from an old router—and explains why a given protocol wins that job. It also names the deprecated and proprietary protocols vendors quietly bury in their settings, so you know what to avoid and what the branded names really mean.

The 30-second decision tree

If you remember nothing else, remember this mapping from task to protocol:

• Phone that constantly switches Wi-Fi to cellular → IKEv2/IPsec. Its MOBIKE extension keeps the tunnel alive through network changes without a visible drop.

• Censorship or a network that blocks VPNs → OpenVPN over TCP port 443 (or a vendor's obfuscated mode). It can be made to look like ordinary HTTPS traffic.

• Streaming, gaming, large downloads, day-to-day use → WireGuard. Lowest latency and highest throughput of the three, with modern cryptography.

• Maximum compatibility on an old router, NAS, or weird OS → OpenVPN. It runs almost everywhere and has been ported to nearly every platform.

• You have no specific need → leave it on the app's default, which is almost always WireGuard or a WireGuard-based build.

Everything below explains the reasoning behind those picks so you can override the default with confidence when your situation calls for it.

The numbers: speed, overhead, and auditability

These are the dimensions that actually differ between protocols. Treat the throughput and latency figures as directional—your real speed depends far more on server load, distance, and your own connection than on the protocol—but the relative ordering is consistent across independent tests and the WireGuard project's own benchmarks.

• Throughput: WireGuard is the fastest of the three. In the WireGuard project's published benchmark it pushed roughly 1,011 Mbps versus about 258 Mbps for OpenVPN on the same hardware; IKEv2/IPsec typically lands between the two.

• Latency / overhead: WireGuard adds the least round-trip delay—often a fraction of a millisecond of processing overhead—because its crypto is lighter and it lives in the kernel. OpenVPN, running in user space with a heavier TLS handshake, adds the most.

• Codebase size and auditability: WireGuard's Linux implementation is famously under ~4,000 lines of code. OpenVPN is tens of thousands of lines and leans on a separate crypto library (OpenSSL or mbedTLS), pushing the realistically auditable surface into the hundreds of thousands of lines. A smaller codebase means fewer places for bugs to hide and a review a single expert can actually finish.

• Reconnection behavior: WireGuard is connectionless and 'always on'—if the link drops and returns, it simply resumes with the next packet. IKEv2 reconnects fast and, with MOBIKE, migrates across networks without dropping. OpenVPN must rebuild its TLS session, so reconnects are the slowest and most visible.

• Transport: WireGuard is UDP-only. OpenVPN runs over UDP or TCP. IKEv2/IPsec uses UDP (ports 500 and 4500).

WireGuard was merged into the mainline Linux kernel in version 5.6 in March 2020, which is part of why it performs so well: kernel-space packet handling avoids the context-switching tax that user-space protocols pay.

Roughly 4,000 lines you can read in an afternoon versus a crypto stack you'd need a team to audit—that single fact explains most of WireGuard's reputation.

Why WireGuard wins on speed and trust

WireGuard's speed isn't marketing; it's a consequence of design choices. It uses a fixed, modern set of cryptographic primitives—ChaCha20-Poly1305 for authenticated encryption, Curve25519 for key exchange, BLAKE2s for hashing, built on the Noise protocol framework—rather than OpenVPN's negotiable menu of ciphers. No negotiation means no slow handshake round-trips and no risk of being downgraded to a weak cipher.

The tiny codebase is the trust story. Security comes from code that can be reviewed, and a 4,000-line module is something auditors have actually read end to end. WireGuard also runs silently: it sends no packets when there's nothing to transmit, so a connection survives sleep, suspend, and idle periods and 'wakes up' instantly. That combination of raw speed, low latency, and reviewability is why it's the right default for streaming, gaming, downloads, and ordinary browsing.

Why IKEv2/IPsec wins on mobile

The killer feature for phones is MOBIKE—the IKEv2 Mobility and Multihoming Protocol, standardized as RFC 4555. When you walk out of your house and your phone hands off from Wi-Fi to LTE, your device's IP address changes. With most protocols that means the tunnel breaks and has to be rebuilt. MOBIKE lets the existing IKEv2 security association move to the new IP address without tearing down and re-establishing the tunnel, so the VPN stays up through the switch with no visible interruption.

IKEv2 is also natively supported on iOS, macOS, and Windows, so it needs no third-party app to run. It reconnects very quickly after a real drop, which makes it excellent for spotty cellular coverage. Its weakness is censorship resistance: it relies on fixed UDP ports (500 and 4500) that a determined firewall can simply block, and unlike OpenVPN it can't easily hide inside HTTPS. WireGuard handles roaming well too thanks to its connectionless design, but IKEv2's MOBIKE remains the gold standard for seamless, invisible mobile handoff.

Why OpenVPN still wins on restrictive networks

OpenVPN's superpower is camouflage. Because it can run over TCP on port 443—the same transport and port as normal HTTPS web traffic—a VPN connection can be made very hard to distinguish from someone simply loading websites. On networks that block VPNs by spotting their traffic signatures or blocking UDP entirely, this is often the only thing that gets through. WireGuard, being UDP-only on a non-standard port, is comparatively easy to fingerprint and block, which is why providers wrap it in extra obfuscation layers for censored regions.

OpenVPN is also the compatibility champion. It has been ported to virtually every operating system, router firmware (DD-WRT, OpenWrt, pfSense), and NAS platform, so when nothing else will install, OpenVPN usually will. The tradeoff is speed: the user-space architecture and TLS overhead make it the slowest of the three, and TCP mode adds its own penalty.

OpenVPN TCP vs UDP, explained

When you pick OpenVPN you also pick a transport, and the choice is a genuine tradeoff:

• UDP is the faster, default choice. It doesn't guarantee delivery or ordering, which is fine because the protocols inside your tunnel (like TCP itself) handle that. Use UDP for everything unless it doesn't connect.

• TCP guarantees in-order, reliable delivery and—crucially—traverses firewalls and proxies that only permit TCP, especially on port 443. The cost is the TCP-over-TCP problem (sometimes called 'TCP meltdown'): when your tunnel's TCP and your traffic's TCP both try to recover from loss at once, throughput can collapse. Reach for TCP only when UDP is blocked or unstable.

The protocols vendors bury: PPTP, L2TP/IPsec, and proprietary builds

Some protocols are still in dropdown menus for legacy reasons. Know which to avoid.

• PPTP — do not use. Point-to-Point Tunneling Protocol dates to the 1990s and its MS-CHAPv2 authentication has been practically breakable for over a decade. It's fast only because it's barely protecting you. Treat it as obsolete; it survives in menus purely for ancient compatibility.

• L2TP/IPsec — weigh carefully. L2TP provides no encryption on its own, so it's always paired with IPsec. It's widely supported and acceptable when configured well, but it's slower than the modern options, uses fixed ports that are easy to block, and there has been longstanding speculation about IPsec being weakened. There's rarely a reason to choose it over IKEv2 (which is also IPsec-based) or WireGuard.

• SSTP — niche. A Microsoft protocol that runs over TLS/443 (so it has OpenVPN-like firewall traversal) but is essentially Windows-only and closed source. Fine in a pinch on Windows; not a first choice.

Then there are the branded protocols. The marketing names hide a simpler reality, and it pays to cut through it:

• NordLynx (NordVPN) is WireGuard with a custom double-NAT system layered on top to fix WireGuard's privacy quirk (more on that next). Under the hood it is WireGuard.

• Many providers' 'proprietary' fast protocol is simply WireGuard with a different label and some obfuscation—Mullvad, Surfshark, and others run WireGuard directly or lightly wrapped.

• Lightway (ExpressVPN) is the genuine exception: it's an open-source, from-scratch lightweight protocol built on the wolfSSL crypto library, not a WireGuard fork—but it shares WireGuard's design philosophy of a small, auditable codebase and fast reconnects.

• Catapult Hydra (Hotspot Shield) is a closed, proprietary transport. Closed protocols can't be independently audited the way WireGuard and OpenVPN can, which is a meaningful trust downgrade.

WireGuard's privacy catch—and how providers fix it

WireGuard has one real weakness for commercial VPNs, and it's worth understanding rather than fearing. By design, WireGuard pairs each user's public key with a static internal IP address inside the tunnel, and the server keeps that association in memory for the session. In a privacy-focused service that's awkward: a fixed internal IP tied to your key, plus the last-seen endpoint WireGuard retains, could in principle be used to link your activity across a session—the opposite of what a no-logs VPN promises.

Reputable providers engineer around this rather than store it. NordLynx's double NAT is the well-documented approach: a second network address translation layer lets the server assign internal addresses dynamically and avoid keeping any identifiable static IP mapped to your account. Others rotate keys frequently or assign addresses per session. The takeaway: WireGuard itself is excellent, but on a commercial service the provider's implementation around it matters, so this is a fair question to ask of any vendor.

Practical takeaways: when to override the default

Leave automatic mode on for everyday use—your app almost certainly defaults to WireGuard, and that's the right call for speed and security. Open the protocol menu and change it deliberately in these cases:

1. You're on a phone that keeps dropping the tunnel during commutes → switch to IKEv2 for MOBIKE's seamless handoff.

2. The VPN won't connect at all on a hotel, campus, workplace, or censored network → switch to OpenVPN over TCP 443, or enable the app's obfuscation/stealth mode.

3. You need it on a router, NAS, or older device → use OpenVPN, the most widely ported option.

4. You care most about the smallest auditable codebase and lowest latency → stay on WireGuard.

5. You see PPTP in the list → never select it. If only PPTP and L2TP are offered, prefer L2TP/IPsec, but treat that as a sign to pick a better-equipped service.

There is no single 'best VPN protocol'—there's the best protocol for the task in front of you. WireGuard for speed and trust, IKEv2 for mobile, OpenVPN for stealth and compatibility, and the deprecated options for nothing at all. Knowing which is which is the difference between a VPN that quietly works and one that fails exactly when you need it.

Frequently Asked Questions

Is WireGuard or OpenVPN better?

For speed, latency, and a small auditable codebase, WireGuard wins—it's faster and far simpler to review. OpenVPN is better when you need to disguise traffic as HTTPS on a restrictive network (over TCP 443) or run on unusual devices like routers and NAS boxes. For most people on everyday connections, WireGuard is the better default.

Is IKEv2 better than WireGuard for mobile?

IKEv2 has the edge for seamless mobile handoff because of MOBIKE (RFC 4555), which moves an active tunnel to a new IP address when your phone switches from Wi-Fi to cellular without dropping. WireGuard also roams well thanks to its connectionless design, but IKEv2's MOBIKE remains the gold standard for invisible network switching, and it's built into iOS, macOS, and Windows.

What is the best VPN protocol overall?

There isn't one best protocol—it depends on the task. Use WireGuard for speed and security, IKEv2 for mobile devices that change networks often, and OpenVPN over TCP 443 for censored or VPN-blocking networks. If you have no specific need, your app's default (usually WireGuard) is the right choice.

Should I use OpenVPN over TCP or UDP?

Use UDP by default—it's faster and the protocols inside your tunnel handle reliability themselves. Switch to TCP, especially on port 443, only when UDP is blocked or unstable, because TCP traverses strict firewalls but can suffer the 'TCP-over-TCP' meltdown that tanks throughput under packet loss.

Is PPTP safe to use in 2026?

No. PPTP's MS-CHAPv2 authentication has been practically breakable for over a decade, so it offers little real protection despite being fast. It only remains in app menus for legacy compatibility. Use WireGuard, IKEv2, or OpenVPN instead, and never select PPTP.

Is NordLynx just WireGuard?

Yes—NordLynx is WireGuard with a custom double-NAT layer added on top. The double NAT solves WireGuard's privacy quirk of pairing a static internal IP with each user's key, letting the server assign addresses dynamically so nothing identifiable is stored. Many other 'proprietary' fast protocols are likewise WireGuard under a brand name.

Does WireGuard have a privacy problem?

By design WireGuard assigns each user a static internal IP tied to their public key and the server keeps that mapping for the session, which could link activity on a commercial VPN. Reputable providers mitigate this with dynamic double-NAT, frequent key rotation, or per-session addressing, so the protocol is excellent as long as the provider implements it carefully.