VPN Protocols Explained: OpenVPN vs. WireGuard vs. IKEv2

What is a VPN protocol, and why should you care which one you use?

Every VPN connection needs an agreed-upon set of rules for how your device and the VPN server authenticate each other, exchange encryption keys, package your data into encrypted packets, and keep the connection alive as your network conditions change. That set of rules is the VPN protocol. It's a different layer from the VPN service you subscribe to — the same provider might offer several protocols as options inside one app — and it's a different layer from the encryption cipher, too, though the two are related: a protocol typically specifies which cipher it uses, or gives you a short list to choose from.

Most people never open the settings menu where the protocol choice lives, and for casual browsing that's often fine — a well-run provider picks a sensible default. But the protocol you're on quietly shapes three things that matter in daily use: how fast your connection feels, how reliably it survives switching networks or waking your device from sleep, and how much independent scrutiny the underlying code has actually received. This VPN protocols explained guide walks through the three protocols you'll actually encounter in a modern VPN app — OpenVPN, WireGuard, and IKEv2/IPsec — plus the older ones you should know to avoid, so the dropdown stops being a mystery.

How does a VPN protocol actually work, in plain terms?

Strip away the acronyms and every VPN protocol is solving the same basic problem in roughly the same order. First, your device and the VPN server need to authenticate each other, so you're not accidentally handing your traffic to an impostor server. Second, both sides need to agree on a shared encryption key without ever transmitting that key across the network in a readable form — this step uses public-key cryptography, which is computationally expensive but only has to happen once per session (or once per key rotation). Third, once that shared key exists, your actual traffic gets wrapped in a fast symmetric cipher — commonly AES-256 or ChaCha20 — for the duration of the connection, because symmetric encryption is dramatically cheaper to run continuously than public-key cryptography would be.

Where protocols genuinely differ from each other is in the engineering choices layered on top of that shared skeleton: which specific cryptographic algorithms they use by default, how much of that is configurable versus fixed, how the connection behaves when your IP address changes mid-session, how large and auditable the underlying codebase is, and which network ports and transport types (UDP or TCP) they can run over. Those differences are what actually show up as "this one feels faster" or "this one survives switching from Wi-Fi to mobile data better" in day-to-day use.

VPN protocols explained at a glance: a quick comparison table

Before going deeper into each one individually, here's how OpenVPN, WireGuard, and IKEv2/IPsec stack up on the dimensions that matter most in practice. Treat this as a starting orientation rather than the final word — the sections below explain the reasoning behind each row.

Protocol	Typical speed	Codebase size	Best suited for	Network reconnection
WireGuard	Fast	Small (roughly a few thousand lines)	General daily use, streaming, most situations	Fast, with proper implementation
OpenVPN	Moderate	Large, decades of review	Restrictive networks, maximum configurability	Slower than WireGuard
IKEv2/IPsec	Fast	Moderate	Mobile devices switching networks	Very fast (built for this)

A brief history: how did VPN protocols get from PPTP to WireGuard?

It's easier to understand why today's protocols are built the way they are with a rough sense of the timeline behind them. PPTP shipped in the mid-1990s, built into early versions of Windows, at a time when VPN use was mostly a corporate networking concern rather than a consumer privacy tool — its authentication weaknesses weren't fully understood and publicized until years later. L2TP arrived shortly after, generally paired with IPsec for encryption since L2TP itself doesn't encrypt anything on its own, and became a common corporate and consumer standard through the 2000s.

OpenVPN launched in 2001 and represented a real step forward: it was open-source from the start, meaning its code could be inspected by anyone rather than trusted on faith, and it used TLS — the same well-studied protocol family that secures HTTPS web traffic — for its handshake. IKEv2 followed in the mid-2000s as an IETF standard, refined over time and eventually paired with the MOBIKE extension that gives it its mobile-friendly reconnection behavior. WireGuard is the newest of the group by a wide margin: its creator began publishing the design in 2015-2016, it was merged into the Linux kernel in 2020, and it's really only in the last several years that it has gone from "promising newcomer" to "default option in most major VPN apps." That relative youth is worth keeping in perspective — it means WireGuard has had less cumulative real-world scrutiny than OpenVPN's two-plus decades, even though its design and the review it has received so far are both strong.

What network ports do these protocols use, and does that matter to you?

Each protocol has typical default ports, though many providers allow some flexibility here. OpenVPN commonly runs on UDP port 1194 by default, with TCP port 443 available as the disguise-friendly alternative discussed earlier. WireGuard has no single official default port and providers can configure it on essentially any UDP port they choose, which is part of why it doesn't have the same "looks like normal web traffic" option that OpenVPN over TCP 443 has — its distinct traffic pattern can, in principle, be identified by sophisticated network filtering even if the specific port varies. IKEv2 typically uses UDP ports 500 and 4500 for its key exchange and NAT traversal.

For most home and mobile connections, none of this requires any action on your part — the VPN app handles port selection automatically. It becomes relevant mainly in two situations: if you're on a network with a restrictive firewall that blocks specific ports (in which case OpenVPN over TCP 443 is the most likely to get through, since blocking it would also block ordinary secure web browsing), or if you're configuring a router-level VPN setup yourself and need to open a specific port manually. If you're just using a standard consumer VPN app, this is background detail rather than something you need to actively manage.

What is OpenVPN, and when should you still use it?

OpenVPN has been in wide public use since the early 2000s, which makes it the most extensively battle-tested protocol on this list simply by virtue of time — two decades of independent security researchers, open-source contributors, and adversarial testing have picked over its implementation. It's open-source, runs on essentially every platform, and can operate over either UDP (faster, less overhead) or TCP (more reliable on networks that drop or shape UDP traffic). That TCP option, specifically running over port 443 — the same port normal HTTPS web traffic uses — is OpenVPN's standout practical advantage: on a restrictive network that blocks or throttles unfamiliar traffic patterns, such as some corporate networks, school networks, or networks in countries that actively interfere with VPN traffic, OpenVPN over TCP 443 is harder to distinguish from ordinary encrypted web browsing than most alternatives.

The tradeoff is configurability cutting both ways. OpenVPN supports a wide range of cipher and authentication combinations, which is powerful in the hands of a provider that configures it carefully, but it also means a poorly configured OpenVPN setup can be meaningfully weaker than a well-configured one — the protocol itself doesn't enforce a single "correct" configuration the way a narrower protocol does. In practice, this is less of a concern with the major providers covered on this site, since they control both ends of the connection and configure OpenVPN themselves rather than leaving it to the end user. OpenVPN also tends to run somewhat slower than WireGuard on the same hardware and connection, largely because of its larger processing overhead per packet, though the difference is often not dramatic on a fast, low-latency connection.

What is WireGuard, and why did it become the new default for most providers?

WireGuard is the newest of the three major protocols, and it was designed from the ground up around a specific philosophy: keep the codebase small, use a fixed and modern set of cryptographic primitives instead of a long configurable menu, and optimize hard for speed and simplicity. Its core implementation runs to roughly a few thousand lines of code, compared to OpenVPN's codebase which is an order of magnitude larger — and in security-critical software, a smaller codebase is genuinely valuable because there's simply less surface area for bugs to hide in, and what is there can be reviewed by a human being in a reasonable amount of time.

WireGuard's cryptography is not configurable by design: it uses ChaCha20 for encryption, Curve25519 for key exchange, and BLAKE2s for hashing, full stop. That rigidity is a deliberate tradeoff — you lose OpenVPN's flexibility, but you also lose the ways that flexibility can go wrong through misconfiguration. In independent testing across the industry, WireGuard has consistently shown faster throughput and lower latency than OpenVPN on comparable hardware, along with quicker reconnection after a network interruption, which is part of why it's become the default protocol for most major VPN apps released or updated in the last several years.

One early technical criticism of WireGuard is worth mentioning honestly rather than glossing over: in its original, minimal specification, WireGuard on its own doesn't include a mechanism for dynamically assigning and rotating IP addresses the way some other protocols do, which raised privacy questions about a static internal IP tying sessions together on a given server. In practice, the VPN providers actually implementing WireGuard address this at the application layer — with mechanisms for periodically rotating the IP address assigned to a device and not persisting logs tied to it — rather than it being a flaw in how any major provider on this site has deployed it. It's a good example of why the underlying protocol and a specific provider's implementation of it are two different things worth being aware of separately.

What is IKEv2/IPsec, and why do mobile apps favor it?

IKEv2 (Internet Key Exchange version 2) is usually paired with IPsec, which handles the actual encryption once IKEv2 has negotiated the connection parameters. It's built into the native networking stacks of several mobile and desktop operating systems, which historically made it a low-overhead, no-extra-software option for phone VPN apps. Its defining practical strength is a feature called MOBIKE (Mobility and Multihoming Protocol), which lets a VPN connection survive a change in the underlying network — say, your phone moving from home Wi-Fi to cellular data as you walk out the door — without the tunnel dropping and needing to fully re-establish itself. For anyone using a VPN primarily on a phone that moves between networks throughout the day, this is a genuinely noticeable, practical advantage over protocols that handle network changes less gracefully.

IKEv2/IPsec is generally considered solid from a security standpoint when properly implemented, and its performance is competitive with WireGuard in many real-world tests, particularly on mobile. Its main relative weakness is that it's less commonly available as an option on desktop apps compared to phone apps, and it can be more prone to being blocked by restrictive firewalls than OpenVPN over TCP 443, since its traffic pattern is more distinctive and easier for network equipment to identify and filter.

OpenVPN vs. WireGuard vs. IKEv2: which protocol is actually fastest?

Across independent testing done by various technology publications and by VPN providers themselves, WireGuard and IKEv2/IPsec typically outperform OpenVPN on raw throughput and latency, with WireGuard usually coming out slightly ahead of IKEv2/IPsec in comparisons that test both, thanks to its lighter processing overhead per packet. OpenVPN over UDP is meaningfully faster than OpenVPN over TCP, since TCP's additional reliability guarantees add overhead that isn't needed for most VPN use cases — but even OpenVPN over UDP tends to trail WireGuard on comparable hardware and connections.

That said, "fastest" in any specific test is also heavily influenced by variables that have nothing to do with the protocol itself: server distance from you, how loaded that particular server is at that moment, your own connection's baseline speed, and even which specific implementation and configuration a provider has deployed. A slow WireGuard connection to an overloaded, distant server will lose to a fast OpenVPN connection to a nearby, lightly loaded one every time. If raw speed matters most to you, testing a couple of protocol options against a couple of nearby server locations in your own setup will tell you more than any general benchmark, including this one.

Which VPN protocol is most secure?

All three of the modern protocols covered here — OpenVPN, WireGuard, and IKEv2/IPsec — are considered cryptographically sound by the security research community when properly implemented, and none has a known practical attack that lets someone without the key recover your traffic in a realistic timeframe. Security differences between them today are less about "can the encryption be broken" and more about auditability, implementation maturity, and how much room each protocol leaves for a mistake in configuration.

On auditability, WireGuard's small codebase is a genuine advantage — a smaller amount of code is inherently easier for security researchers to review thoroughly, and its cryptographic choices are fixed rather than configurable, closing off an entire category of "insecure configuration" risk. On track record, OpenVPN's two decades of public, adversarial scrutiny is its own kind of strength — it has been attacked, studied, and patched in the open for far longer than WireGuard has existed, which is a meaningful form of validation in its own right. IKEv2/IPsec sits between the two in terms of independent public scrutiny, but is generally regarded as secure when implemented correctly, and it benefits from being built into operating system networking stacks that have themselves received significant security attention.

The practical takeaway is that for the three protocols discussed in this guide, protocol choice is not where most of the real-world security risk in using a VPN actually lives. A provider's logging policy, jurisdiction, app security practices, and how it handles the moment traffic is decrypted at its servers matter more to your overall security and privacy posture than which of these three well-regarded protocols you happen to be connected through on a given day.

Which protocol handles switching networks best — Wi-Fi to mobile data and back?

This is specifically IKEv2/IPsec's strongest use case, thanks to the MOBIKE extension mentioned earlier, which was purpose-built to let a session survive an underlying network change without a full reconnection. WireGuard also handles network changes reasonably well in modern implementations — its stateless design means it doesn't need a lengthy renegotiation the way older protocols might — though the seamlessness depends somewhat on how a given provider's app has implemented reconnection logic on top of the base protocol. OpenVPN tends to be the least graceful of the three here; a network change is more likely to require the connection to drop and fully re-establish, which you'd notice as a brief pause or a "reconnecting" message in the app.

If you're mostly using a VPN on a phone that moves between home Wi-Fi, public Wi-Fi, and cellular data throughout a typical day, this is a legitimate reason to prefer IKEv2/IPsec or WireGuard over OpenVPN specifically for that device, even if you use OpenVPN elsewhere for a specific reason like a restrictive network.

What about proprietary protocol names like NordLynx?

Several providers market their own named protocol rather than just listing "WireGuard" or "OpenVPN" in their app. NordVPN's NordLynx, for example, is described by the company as being built around the WireGuard protocol with an additional layer addressing the static-IP privacy consideration mentioned earlier. Other providers take a similar approach with their own purpose-built or WireGuard-derived protocols, generally aiming for the same goals of speed and a small attack surface. When you encounter a provider-specific protocol name, it's worth treating it as that provider's particular engineering approach and implementation rather than an entirely different category of technology — the underlying goals (fast handshake, strong modern cipher, small attack surface) are usually similar across these proprietary options and the open protocols they're often built on or inspired by.

We'd encourage reading a provider's own technical documentation for the specifics of how their named protocol works and what's been published about it, rather than taking a marketing page's claims at face value — and checking whether the provider has made any of that implementation open to independent review, since that's a meaningfully stronger signal than a company's own description of its own protocol.

What happened to PPTP and L2TP/IPsec? Are they still safe to use?

PPTP (Point-to-Point Tunneling Protocol) is the oldest VPN protocol still occasionally seen in the wild, dating back to the 1990s. It has well-documented, long-standing security weaknesses in its authentication method, and it should not be used for anything where privacy or security matters — if you see PPTP listed as an option in a VPN app today, treat that as a sign the app is offering a legacy compatibility option, not a recommendation to use it. Reputable modern VPN providers generally don't offer it at all anymore.

L2TP/IPsec is a step up from PPTP and isn't broken in the same fundamental way, but it's still considered a legacy option today, generally slower than the modern alternatives due to double encapsulation overhead, and it has faced historical concerns (some tied to how certain implementations handled pre-shared keys) that mean it doesn't carry the same confidence as OpenVPN, WireGuard, or IKEv2/IPsec. If a provider offers OpenVPN, WireGuard, or IKEv2/IPsec alongside L2TP/IPsec, there's little practical reason to choose the older option.

How is a protocol's security actually verified, rather than just claimed?

It's worth being clear-eyed about what "secure protocol" actually rests on, since it's easy to treat these claims as settled facts rather than ongoing processes. For an open-source protocol like OpenVPN or WireGuard, the source code itself is publicly available, which means independent researchers, academic teams, and other developers can — and regularly do — read it, test it, and publish findings when they find weaknesses. This ongoing, adversarial public review is a large part of why both are trusted today: it's not that either protocol has been declared perfect once and never revisited, it's that they've been exposed to continuous scrutiny over years without a fundamental cryptographic break being found.

Formal third-party security audits — where a specialized firm is paid to systematically review an implementation and publish a report — add another layer of confidence beyond general public review, and some VPN providers commission these for their specific app implementations of a protocol, not just the protocol specification itself. When a provider references an audit, it's worth checking whether they link to the actual report and note its date and scope, the same way this site treats no-logs audit claims elsewhere — a specific, dated, scoped audit is meaningfully more informative than a general "independently audited" badge on a marketing page. IKEv2/IPsec benefits somewhat differently: because it's built into mainstream operating system networking stacks, it inherits scrutiny from the broader security review those operating systems receive, though that's a less direct form of validation than a protocol-specific audit.

Do business and enterprise VPNs use different protocols?

Enterprise and site-to-site VPN deployments sometimes use additional protocols you're less likely to encounter in a consumer app, worth knowing about if you've heard the names elsewhere. SSTP (Secure Socket Tunneling Protocol) is a Microsoft-developed protocol that, like OpenVPN over TCP 443, tunnels through a port that looks like ordinary HTTPS traffic, but it's tied more closely to Windows environments and sees less use in cross-platform consumer VPN apps. SoftEther is an open-source, multi-protocol VPN platform that can itself speak several of the protocols discussed in this guide alongside its own; it shows up more often in self-hosted or enterprise contexts than in the major consumer providers this site covers. None of these are protocols you need to evaluate when choosing a consumer VPN provider — they're mentioned here mainly so the names don't seem mysterious if you come across them in a work or IT context, since the underlying tradeoffs (codebase size, auditability, platform support, disguise-friendliness) are the same considerations already covered above.

Which VPN protocol should you use for streaming?

Streaming rewards raw throughput and low, consistent latency more than almost any other common use case, since a stalled or buffering stream is immediately obvious in a way that a slightly slower page load isn't. WireGuard's speed advantage makes it a sensible default choice for streaming if your provider offers it, and IKEv2/IPsec is a reasonable second choice for the same reason. OpenVPN can still stream perfectly well, particularly over UDP, but if you're specifically chasing the smoothest possible experience on a slower connection or during peak network congestion, the lighter protocols have a real edge. Beyond protocol choice, server selection tends to matter just as much for streaming performance — a nearby, lightly loaded server on OpenVPN can easily outperform a distant, congested server on WireGuard.

Which VPN protocol is best for gaming?

Gaming, especially anything real-time and competitive, is sensitive to latency (ping) and connection stability more than to raw download throughput. WireGuard's lightweight packet processing generally gives it an edge on latency compared to OpenVPN, and its efficient design tends to produce more consistent ping times, which matters more for a smooth gaming experience than a marginally higher theoretical max speed. IKEv2/IPsec is also a reasonable choice for the same underlying reasons. As with streaming, though, protocol is only one variable — connecting to a VPN server that's geographically close to the game server you're trying to reach will typically affect your measured latency more than the protocol choice does, so it's worth testing a couple of nearby locations rather than assuming the "fastest" protocol alone will solve a ping problem.

Which protocol should you use on public Wi-Fi?

On public Wi-Fi, the priority shifts slightly: you want a protocol that connects reliably, reconnects quickly if the network is flaky (which public Wi-Fi often is), and doesn't leave gaps where traffic could briefly go out unprotected. WireGuard and IKEv2/IPsec both tend to reconnect faster after a brief drop than OpenVPN does, which matters on the kind of unstable connection you sometimes get at a coffee shop, airport, or hotel. Whichever protocol you're on, the more important safeguard on public Wi-Fi is making sure your VPN app's kill switch is enabled, so that if the connection does drop momentarily, your device's traffic doesn't fall back to the unprotected public network without you noticing.

Does the protocol you choose affect battery life on your phone?

Yes, to a modest degree. WireGuard's design goal of being lightweight in terms of processing overhead generally translates into somewhat lower battery drain compared to OpenVPN running continuously in the background, since less CPU work per packet means less energy spent. IKEv2/IPsec, being built into the mobile operating system's own networking stack on many platforms rather than requiring a separate always-on background process for the tunnel itself, can also be efficient from a battery standpoint. In day-to-day use, though, battery impact from protocol choice alone tends to be a secondary factor compared to things like how frequently the VPN app itself wakes up to check its connection, whether you're on a weak cellular signal (which makes any radio activity, VPN or not, more power-hungry), and how the specific app is engineered — two apps using the same protocol can still have meaningfully different battery behavior based on how well they're built.

UDP vs. TCP: does that transport choice matter too?

This is a related but separate decision that mostly comes up with OpenVPN, which can run over either. UDP (User Datagram Protocol) doesn't guarantee delivery or ordering of packets and has lower overhead, which generally makes it faster and better suited to VPN use, since higher-level protocols and applications already handle retransmission when needed. TCP (Transmission Control Protocol) guarantees delivery and ordering, which adds overhead and can actually make things worse on an already lossy connection — a phenomenon sometimes called "TCP meltdown," where running a protocol that itself retransmits (like some VPN configurations) over a TCP connection that's also retransmitting can compound delays rather than fixing them.

The main reason to deliberately choose OpenVPN over TCP, specifically on port 443, is disguise rather than performance: that combination is much harder for a restrictive network to distinguish from ordinary HTTPS web traffic than OpenVPN over UDP is, which matters if you're on a network that actively blocks or throttles VPN traffic. If you're not dealing with that kind of restrictive network, UDP is generally the better default whenever it's available.

Does protocol support differ across Windows, macOS, iOS, Android, and routers?

To a degree, yes, though the gap has narrowed considerably as WireGuard has matured. OpenVPN has the longest track record of cross-platform support and remains close to universal across desktop and mobile apps, plus router firmware like DD-WRT and OpenWrt for anyone running a VPN directly on a home router rather than per-device. WireGuard support has expanded quickly and is now standard in the major providers' apps across Windows, macOS, iOS, Android, and Linux, and it's increasingly available on router firmware too, though it may lag slightly behind on less common platforms or older router hardware with less processing headroom. IKEv2/IPsec has historically had particularly strong native support on iOS and macOS, since Apple's operating systems have built-in IKEv2 support at the system level, and it's well supported on Windows too; its router-firmware support tends to be somewhat less consistent than OpenVPN's.

If you split your VPN use across several kinds of devices — say, a phone, a laptop, and a router — it's worth checking the protocol list in each specific app rather than assuming parity, since a provider's mobile app and desktop app aren't guaranteed to expose identical options even though most modern providers try to keep the core three (OpenVPN, WireGuard, IKEv2/IPsec) available wherever the underlying platform allows it.

How do you actually change your VPN protocol?

In most VPN apps, the protocol selector lives in a settings menu, often labeled "Protocol," "Connection," or "VPN Protocol," separate from the main server-selection screen. The available options and the default vary by provider and by platform — a provider's desktop app and mobile app don't always offer identical protocol lists, since some protocols are more natural fits for certain operating systems. A few practical points worth knowing:

• "Automatic" is a reasonable default. Many apps default to an automatic mode that picks a protocol based on your network conditions. This is a sensible starting point for most users, and you can always override it if you have a specific reason to.
• Changing protocol usually requires reconnecting. Switching protocols typically drops and re-establishes your VPN connection, so it's not something you'd want to do mid-download or mid-call if you can avoid it.
• Not every protocol is available on every platform. IKEv2/IPsec in particular is more commonly available on mobile apps than on some desktop clients, depending on the provider.
• Test before you commit to a change. If you're troubleshooting a specific problem — slow speeds, frequent disconnects, a site or service blocking your VPN's traffic pattern — try switching protocols as a diagnostic step, and give each option a real few minutes of actual use rather than judging from the first few seconds of a fresh connection.

Do you need to think about any of this, or should you just use the default?

For most people, most of the time, the honest answer is that you can just use whatever protocol your VPN app defaults to, and it will be fine. The major providers covered on this site have generally moved toward WireGuard or a WireGuard-based proprietary protocol as their default specifically because it performs well for the widest range of everyday use cases, so the default you're handed is usually already a reasonable one rather than an afterthought. Where it's worth actively overriding the default is in the specific situations this guide has walked through: OpenVPN over TCP 443 if you're on a network that's actively hostile to VPN traffic, IKEv2/IPsec if you're on a phone that moves between networks constantly and notices the tunnel dropping, or simply experimenting with the available options if you're troubleshooting a concrete speed or stability problem rather than a hypothetical one.

Practical takeaway

Having gone through vpn protocols explained one at a time, the practical guidance collapses down to a short list. WireGuard is the strongest general-purpose default today, combining speed, a small and auditable codebase, and modern fixed cryptography — use it, or a provider's WireGuard-based implementation, unless you have a specific reason not to. OpenVPN remains a dependable, thoroughly reviewed option, and specifically valuable over TCP port 443 on restrictive networks where disguising VPN traffic as ordinary HTTPS matters more than raw speed. IKEv2/IPsec earns its place primarily on mobile devices, where its network-switching resilience is a real, noticeable advantage over the other two. And PPTP and plain L2TP/IPsec belong in the past — avoid the former outright and treat the latter as a fallback only when nothing newer is offered. None of this requires becoming a cryptography expert; it just requires knowing which of three or four buttons to press for your specific situation, which is exactly what this guide was built to make easy.