VPN Protocols Compared: WireGuard, OpenVPN, IKEv2 in 2026

Open your VPN app’s settings and you’ll usually find a protocol dropdown: WireGuard, OpenVPN (UDP), OpenVPN (TCP), maybe IKEv2, and an “automatic” option that’s selected by default. Most of the time, leaving it on automatic is the right call. This guide is about the handful of situations where it isn’t — and what the three VPN protocols still in active use, WireGuard, OpenVPN, and IKEv2, actually trade off in 2026.

The short version: on a modern connection, the protocol you pick barely affects raw speed anymore. What it affects is how the connection behaves when your network changes, whether it survives a censor actively looking for VPN traffic, and how much can go wrong in the implementation. Those are the axes that still matter.

The Three That Matter

Protocol	Transport	Reconnects fast on network change	Resists active VPN blocking	Best left to
WireGuard	UDP only	Yes (roaming built in)	No (needs a separate obfuscation layer)	Default for almost everything
OpenVPN	UDP or TCP	No (full renegotiation)	Better — TCP mode on port 443 looks like HTTPS	Restrictive networks; when only port 443 is open
IKEv2/IPsec	UDP 500 + 4500	Yes (via MOBIKE)	No — fixed ports are trivial to scan for	Native mobile clients where it’s still supported

Everything below expands on that table. PPTP and L2TP aren’t in it — PPTP’s encryption was broken over a decade ago, to the point that Microsoft’s own security advisory tells people to stop using it, and L2TP/IPsec has been overtaken on every axis by the three above. If your app still lists them, don’t pick them.

WireGuard

WireGuard is the newest of the three and the default in nearly every consumer VPN app today. Its design goal was to be small enough to audit: the Linux implementation is roughly 4,000 lines of code, against tens of thousands for the alternatives. It uses one fixed set of cryptographic primitives — ChaCha20-Poly1305 for encryption, Curve25519 for key exchange, BLAKE2s for hashing — with no negotiation, so there’s no weak cipher for a client and server to accidentally agree on. It runs over UDP, and only UDP.

What it’s genuinely good at. Two things. First, it reconnects seamlessly when your network changes — switch from Wi-Fi to cellular, or your phone wakes from sleep, and the tunnel just continues, because WireGuard identifies a peer by its cryptographic key rather than its IP address. Second, it runs in the operating system kernel rather than as a user-space program, which historically gave it a real efficiency and latency advantage over OpenVPN.

Where the “fastest protocol” claim has aged. WireGuard’s reputation for crushing everything on speed rests on a benchmark table from its own 2017 whitepaper that showed it at roughly 1,000 Mbps against OpenVPN’s 258. WireGuard’s own performance page has since replaced that table with a disclaimer: the old benchmarks are “old, crusty, and not super well conducted,” WireGuard and IPsec “have both gotten faster,” and replacing the numbers “is a work in progress.” The most recent independent head-to-head test — a December 2025 evaluation from researchers at Adtran, the German Research Center for AI, and TU Ilmenau, run on a live 5G test network — found WireGuard had lower latency overhead than IKEv2/IPsec (about 2.2 ms added versus 2.9 ms), but IPsec was actually more consistent on throughput and edged WireGuard out by 2–5% across packet sizes. All the protocols they tested added under 1% CPU load. That’s an industrial 5G measurement, not a consumer test, so read it as directional — but the direction is clear: on modern hardware, none of these protocols is a speed bottleneck, and the gap between them is small enough that other factors should decide.

Its real limitation: it doesn’t hide. WireGuard makes no attempt to disguise its traffic. Its own documentation says so directly — “WireGuard does not focus on obfuscation. Obfuscation, rather, should happen at a layer above WireGuard.” Every WireGuard handshake begins with the same recognizable byte, and packets go out at predictable sizes and intervals, so a network doing deep packet inspection can identify and block WireGuard without decrypting anything. This is why providers that market censorship resistance build a separate obfuscation protocol (ProtonVPN’s Stealth, Mullvad’s obfuscation, various “stealth” modes) that wraps WireGuard inside something that looks like ordinary web traffic. Plain WireGuard on a network that’s actively blocking VPNs will usually just fail.

Pick WireGuard when: you want a default. It’s the right choice for everyday use, for anything mobile, and for streaming or downloading where you want low overhead. It is not the right choice, on its own, for a network that blocks VPN traffic.

OpenVPN

OpenVPN is the older standard — first released in 2001, built on the OpenSSL library, open-source and heavily audited over two decades. It’s the protocol with the most options, and two of those options matter here.

UDP versus TCP. OpenVPN can run over either. UDP is the default and the faster of the two: it doesn’t wait for acknowledgment of every packet, so it has less overhead. TCP is slower but more reliable through hostile networks — and, critically, OpenVPN over TCP on port 443 is very hard to distinguish from a normal HTTPS connection to a website, because that’s exactly the port and transport real HTTPS uses. On a corporate firewall, a hotel network, or a country that blocks other VPN protocols, OpenVPN TCP/443 is often the thing that still connects. The tradeoff is a phenomenon sometimes called “TCP meltdown”: running TCP inside TCP means two layers both trying to recover from packet loss at once, which on an already-bad connection can make throughput collapse. Use TCP mode as a fallback, not a default.

The DCO change. OpenVPN’s long-standing weakness against WireGuard was that it ran in user space, not the kernel, which cost CPU and speed. That’s been addressed. Data Channel Offload (DCO) is a kernel module — for Linux, Windows, and FreeBSD — that moves the bulk data encryption into the kernel while keeping the SSL/TLS control channel where it is. It’s been available since OpenVPN 2.6 and is becoming standard in newer releases. Reported throughput gains are large: OpenVPN’s own materials describe roughly an eight-fold increase in one test, and downstream projects have reported single-tunnel throughput going from 1 Gbit/s to 10 Gbit/s. DCO has real constraints — it only works over UDP, only with modern AEAD ciphers (AES-GCM or ChaCha20-Poly1305), not with compression, and not with multi-client server-to-server routing — but for a normal “connect to a VPN server” setup on a current client, “OpenVPN is slow” is now a claim that depends on which version you’re running.

One caveat on obfuscation. OpenVPN’s XOR-patched “scramble” obfuscation is not reliable against a determined censor. Research summarized in a 2025 survey of censorship measurement describes a two-stage method — passively fingerprinting OpenVPN’s packet patterns, then confirming with active probing — that works “even with obfuscation enabled,” and a separate statistical technique that classified obfuscated VPN traffic with reported accuracy near 99%. OpenVPN TCP/443 gets through many automated blocks by blending in; it is not a guarantee against a state-level system built specifically to find it.

Pick OpenVPN when: WireGuard won’t connect and you need to get through a restrictive network — set it to TCP and port 443. On a current client with DCO, you’re not giving up much speed to do it. On an old client without DCO, expect it to be noticeably slower than WireGuard.

IKEv2/IPsec

IKEv2 is the key-exchange half of an IPsec VPN — the current version, standardized in RFC 7296 in 2014. It’s built into most operating systems natively, which is its main draw: an iOS or Windows device can run an IKEv2 VPN without installing a third-party app.

What it does well. Like WireGuard, it reconnects quickly when your connection changes, through an extension called MOBIKE that updates the tunnel’s addresses instead of rebuilding it when you move between Wi-Fi and cellular. For years this made native IKEv2 the sensible choice on mobile, before WireGuard apps became universal.

Why privacy-focused providers are dropping it. IKEv2 runs on two fixed UDP ports, 500 and 4500. That’s a problem for censorship resistance: anyone can scan an IP range for hosts responding on those ports and flag them as VPN servers, with no packet inspection needed. ProtonVPN is removing IKEv2 from its servers over 2026 — the process starts in April 2026 and finishes in February 2027 — and its stated reasons are exactly this: the fixed ports are “trivially easy to scan for,” censoring countries “actively probe these ports to detect and flag the IP addresses of our VPN servers,” and Apple’s built-in macOS IKEv2 implementation has had “traffic leaks that can expose your real IP address.” Mullvad has gone further in the other direction, dropping OpenVPN entirely on 15 January 2026 to run WireGuard only.

Two things not to confuse this with. First, a critical vulnerability disclosed in 2026 — CVE-2026-33824, a wormable remote-code-execution flaw that CISA added to its known-exploited list in August — is a bug in Microsoft’s Windows IKE service, the specific software, not in the IKEv2 protocol itself. Non-Windows IKEv2 implementations aren’t affected by it. Second, RFC 9395 (2023) deprecated IKEv1, the previous generation — not IKEv2. If a setup screen or an article mentions IKEv1 being retired, that’s a different, genuinely obsolete protocol.

Pick IKEv2 when: you’re on a device where it’s built in, you want a native VPN without installing an app, and you’re not trying to defeat censorship. If your provider is phasing it out, switch to WireGuard now rather than waiting for connections to start failing.

Which Situation, Which Protocol

• Normal daily use, any device: WireGuard, or leave the app on automatic.
• Phone that constantly switches Wi-Fi and cellular: WireGuard. Native IKEv2 also handles this well if your provider still supports it.
• Streaming or large downloads: WireGuard for the lowest overhead. OpenVPN with DCO on a current client is close enough that it’s fine too.
• Restrictive network — office, campus, hotel, some public Wi-Fi: OpenVPN, set to TCP on port 443.
• A country that actively blocks VPNs: none of these three on their own. You need your provider’s dedicated obfuscation mode (often branded “Stealth” or similar), which is usually WireGuard or OpenVPN wrapped in a disguise layer.
• You want a VPN with no third-party app installed: native IKEv2, where it’s still offered — with the caveat that it’s the least future-proof of the three.

What This Site’s Reviews Show

Across the 14 VPNs reviewed here, the protocol lineup has converged. Every one supports WireGuard. Every one still supports OpenVPN today, though that’s changing: Mullvad drops OpenVPN entirely in January 2026 to go WireGuard-only, and ProtonVPN is on the opposite trajectory — keeping OpenVPN but removing IKEv2 through 2026. Eight of the 14 still offer IKEv2; several, including Private Internet Access, never did, offering only WireGuard and OpenVPN.

The practical takeaway matches the rest of this site’s position: the protocol is close to settled, and it’s not what separates a good VPN from a bad one. WireGuard is the sensible default almost everywhere, OpenVPN TCP is the fallback for hostile networks, and IKEv2 is a shrinking option worth migrating off. What still varies between providers — and what actually decides which one to trust — is everything downstream of the tunnel: whether the no-logs claim has been independently audited, which jurisdiction the company answers to, and whether the kill switch actually holds when the connection drops.