WireGuard vs OpenVPN vs IPsec: Which VPN Protocol Should You Use?

By State of Surveillance Published: 2026-09-14 Last Updated: 2026-09-14

TL;DR

WireGuard is the right default for almost everyone. It is faster than OpenVPN on the same hardware, simpler than IPsec to set up, ships in the Linux kernel since 5.6 (March 2020), and has been through formal cryptographic verification with results published in academic venues.[1][2][3] OpenVPN is the right fallback when WireGuard is blocked by a network you are stuck on (older hotel WiFi, restrictive corporate firewalls) or when you need TCP transport to disguise traffic as ordinary HTTPS.[4] IPsec (specifically IKEv2 with ESP) is the right choice for site-to-site and enterprise gateway deployments and for native mobile OS support, but it is a heavy lift for personal use.[5][6]

What a VPN protocol actually does

A VPN protocol is the set of rules two endpoints use to negotiate keys, encrypt packets, and keep a tunnel alive. Three things matter in any of them: how they derive the keys, what ciphers they use, and how they handle the boring-but-hard parts (roaming between networks, dead peers, IP changes).

The three protocols on this page are not equivalent choices. They are three different design bets about what a VPN should optimize for:

  • WireGuard optimizes for a tiny auditable codebase and modern cryptography, all defaults, no configuration knobs.[1]
  • OpenVPN optimizes for flexibility (TCP or UDP, runs anywhere TLS runs, every cipher configurable) and 20 years of accumulated hardening.[4]
  • IPsec (specifically IKEv2 with ESP) optimizes for being a standard baked into operating systems and routers, with site-to-site and gateway-to-gateway scenarios as its native habitat.[5][6]

The rest of this article walks through each one against the same six axes: cryptography, code size and audit, performance, mobile and roaming behavior, NAT/firewall traversal, and known weaknesses.

WireGuard: the modern default

WireGuard is a relatively young VPN protocol written by Jason Donenfeld and merged into the Linux kernel in version 5.6, released in March 2020.[7] It presents itself this way: "an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPsec, while avoiding the massive headache. It intends to be considerably more performant than OpenVPN."[1]

Cryptography

WireGuard has no cipher negotiation. The protocol ships with one fixed suite, and the suite is described directly in the protocol page: "ChaCha20 for symmetric encryption, authenticated with Poly1305, using RFC7539's AEAD construction," "Curve25519 for ECDH," "BLAKE2s for hashing and keyed hashing, described in RFC7693," "SipHash24 for hashtable keys," and "HKDF for key derivation, as described in RFC5869."[2] The handshake builds on the "Noise_IK" framework, "building on the work of CurveCP, NaCL, KEA+, SIGMA, FHMQV, and HOMQV."[2]

There are no configuration knobs for cryptography because there is nothing to configure. A reviewer reading the source is not choosing between AES and 3DES. They are reading one cipher suite.

Code size and audit

The WireGuard project describes itself as "meant to be easily implemented in very few lines of code, and easily auditable." It is "comprehensively reviewable by single individuals," and "compared to behemoths like Swan/IPsec or OpenVPN/OpenSSL, in which auditing the gigantic codebases is an overwhelming task even for large teams of security experts, WireGuard is meant to be" reviewable by a single person.[1] The Mullvad comparison page puts a number on the contrast: "WireGuard is written with less than 7,000 lines of code whereas IPSec contains 400,000 lines."[8]

Formal verification work backs up that claim. The WireGuard formal verification page lists papers covering Curve25519 (both 64-bit scalar multiplication via HACL* and 32-bit scalar multiplication via Fiat-Crypto), the Noise-based protocol, correctness, "Strong key agreement & authenticity," "Key-compromise impersonation resistance," "Unknown key-share attack resistance," "Key secrecy," "Forward secrecy," "Session uniqueness," "Identity hiding," "Message secrecy," "Mutual authentication," and "Replay resistance of the first protocol message."[3] The Tamarin work is described as "a security proof of the WireGuard protocol," and the Lipp thesis is called "a very strong result."[3]

Roaming and mobile

WireGuard handles roaming by design. The protocol rotates keys on a timer (every two minutes, by default),[2] and the cryptokey routing table allows a peer's endpoint to change (a phone moving from WiFi to cellular, for instance) without renegotiating. Mullvad summarizes this as: "WireGuard is written with less than 7,000 lines of code whereas IPSec contains 400,000 lines" and that WireGuard supports mobile use well.[8] The Mullvad page credits WireGuard with being "considerably more performant than OpenVPN" and "faster, simpler, leaner, and more useful than IPsec."[1]

Known weaknesses

WireGuard has two operational limits readers should know about. First, every peer must have a public IP or DNS name that the other side can reach. WireGuard has no built-in NAT traversal layer or peer discovery mechanism the way IKEv2 has NAT-T and MOBIKE.[1] Second, the protocol assigns each peer a static internal IP inside the tunnel, and Mullvad's own documentation flags "static internal IPs" and "WebRTC leak risks" as drawbacks of the protocol.[8]

A separate issue: WireGuard does not pretend to hide that a VPN is in use. The packet headers are distinctive. On networks that block WireGuard outright (some corporate firewalls, some hotel networks), you need OpenVPN over TCP 443 as a fallback.

OpenVPN: the flexible fallback

OpenVPN is an open-source VPN protocol maintained by OpenVPN Inc. and a community. The OpenVPN community page describes the project and explains the trade-offs versus newer protocols.[4]

Cryptography

OpenVPN is the polar opposite of WireGuard on configuration. It uses TLS for key exchange (so you get whatever the TLS 1.2 or TLS 1.3 ecosystem gives you), and it can encrypt the data channel with AES-256-GCM, AES-256-CBC, ChaCha20-Poly1305, or several older ciphers. That flexibility is also a footgun: a server configured with weak ciphers is a real, common misconfiguration.[4]

Performance

OpenVPN runs in user space, not in the kernel, and it runs over either UDP or TCP. The OpenVPN community performance page is blunt about it: the page describes its own benchmarks as "old, crusty, and not super well conducted" and explicitly states that "WireGuard and IPsec have both gotten faster, with WireGuard stil edging out IPsec in some cases due to its multi-threading, while OpenVPN remains extremely slow."[9] The same page acknowledges that its performance numbers are outdated and that the team plans to replace them.[9]

Why OpenVPN is still around

OpenVPN's killer feature is not speed. It is portability. OpenVPN runs over TCP 443, which means it looks like ordinary HTTPS to a network observer and slips past most corporate firewalls, hotel captive portals, and country-level censorship that blocks UDP-based protocols.[4] That is the reason VPN providers ship OpenVPN as a fallback option alongside WireGuard. It is also the reason OpenVPN remains the protocol of choice on networks where WireGuard is blocked.

OpenVPN also runs on every platform that has a TCP/IP stack. Embedded devices, ancient routers, set-top boxes, and obscure NAS firmware are far more likely to ship OpenVPN support than WireGuard.

Known weaknesses

OpenVPN inherits every TLS vulnerability in the version of OpenSSL or mbed TLS it links against. Historically that has mattered: the OpenSSL Heartbleed bug (CVE-2014-0160, disclosed April 2014) was a TLS-layer vulnerability in OpenSSL that affected any application linking against the vulnerable release, including OpenVPN deployments that used OpenSSL for their TLS handshake. The rule still holds: a vulnerability in the underlying TLS library is a vulnerability in your VPN tunnel.

OpenVPN also runs in user space, which means context switches on every packet. The performance hit is real and gets worse on high-throughput links.

IPsec: the standard for site-to-site and mobile OS

IPsec is a suite of protocols defined by the IETF, not a single protocol. The two pieces that matter for VPN use are Encapsulating Security Payload (ESP, RFC 4303) for the encrypted data plane, and Internet Key Exchange version 2 (IKEv2, RFC 7296) for the key management plane.[5][6]

Cryptography

RFC 4303 defines what ESP provides: "ESP can be used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality."[5] The actual algorithms are negotiated and listed in RFC 8247, which updates the IKEv2 algorithm registry.

RFC 8247 sets the policy. For ESP and IKEv2 encryption, AES-CBC (128-bit and 256-bit keys) is "MUST," ChaCha20-Poly1305 and AES-GCM-16 are "SHOULD," and 3DES is "MAY." DES is "MUST NOT" because it "can be brute-forced using off-the-shelf hardware."[10] For integrity, SHA-1 based methods are downgraded. RFC 8247 explains that "cryptographic attacks against SHA1 are increasing" and that HMAC-SHA1 was demoted from MUST to MUST-.[10]

What this means in practice: a modern, properly configured IPsec deployment uses AES-GCM or ChaCha20-Poly1305 with SHA-256 or SHA-384. An older deployment that still defaults to AES-CBC + HMAC-SHA1 is not insecure yet, but it is on borrowed time.

Why IPsec is hard

IPsec's reputation for complexity is earned. ESP and IKEv2 are separate protocols. IKEv2 has its own state machine, its own message types, its own negotiation of cryptographic transforms, and its own set of extensions (MOBIKE for roaming, RFC 4554 for machine certificates, RFC 7427 for signature method agility). The Mullvad comparison puts the size contrast bluntly: "IPsec contains 400,000 lines" of code.[8]

IKEv2 itself was explicitly designed to fix the mess of IKEv1. RFC 7296 obsoletes RFC 5996 and notes that "IKEv2 as stated in RFC 4306 was a change to the IKE protocol that was not backward compatible," and that the revision clarifies ambiguities in earlier SHOULD-level requirements.[6] IKEv1 is now formally deprecated by RFC 9395.[10] If you are using IPsec, use IKEv2.

Where IPsec wins

IPsec is built into operating systems. iOS, macOS, Windows, and Linux all ship native IPsec/IKEv2 clients that do not require third-party software. That is why enterprise IT departments standardize on it: the OS handles the tunnel, the user does not have to install anything, and the configuration can be pushed through mobile device management.

IPsec is also the right answer for site-to-site VPNs (connecting two offices, or an office to a cloud VPC). WireGuard site-to-site setups work but require running WireGuard on a Linux box at each end. IPsec site-to-site is what every commercial firewall and router ships with out of the box.

Known weaknesses

IPsec's complexity is the attack surface. The IKEv2 specification itself acknowledges that "use of IP fragmentation opens an implementation to denial-of-service (DoS) attacks" and that "some NAT and/or firewall implementations may block IP fragments."[6] Implementations have shipped with bugs at the IKE parser level, the ESP replay-window level, and the cryptographic negotiation level.

Historically, certain IPsec configurations using Encapsulating Security Payload in transport mode (instead of tunnel mode) and AH (Authentication Header) instead of ESP have leaked metadata about the original packet. RFC 4303 explicitly removes AH+ESP nesting discussion that was "a mistake in RFC 4306 caused by the lag between finishing RFC 4306 and RFC 4301."[6]

Side-by-side: what each one gives you

Cryptography

  • WireGuard: Fixed suite: ChaCha20-Poly1305, Curve25519, BLAKE2s, HKDF, Noise_IK handshake. No negotiation.[2]
  • OpenVPN: TLS 1.2/1.3 for key exchange; AES-256-GCM, ChaCha20-Poly1305, or AES-256-CBC for the data channel. Configurable per-deployment.[4]
  • IPsec (IKEv2 + ESP): AES-CBC MUST, AES-GCM and ChaCha20-Poly1305 SHOULD per RFC 8247. SHA-1 integrity methods downgraded; SHA-256+ recommended.[10]

Code size

  • WireGuard: "Less than 7,000 lines."[8]
  • OpenVPN: Larger, runs over OpenSSL or mbed TLS for cryptography.
  • IPsec: "IPsec contains 400,000 lines."[8]

Formal verification

  • WireGuard: "Has undergone all sorts of formal verification," including Tamarin proofs of the Noise handshake, ACCE proofs of the key exchange, and verified Curve25519 implementations in HACL* and Fiat-Crypto.[3]
  • OpenVPN: No comparable end-to-end formal verification of the protocol.
  • IPsec: IKEv2 is formally specified in RFC 7296, but the protocol has so many extensions and modes that whole-system verification is impractical.

Performance

  • WireGuard: Kernel-resident, low overhead, fastest of the three on equivalent hardware. "A combination of extremely high-speed cryptographic primitives and the fact that WireGuard lives inside the Linux kernel means that secure networking can be very high-speed."[1]
  • OpenVPN: User-space, runs over UDP or TCP. OpenVPN's own page says "OpenVPN remains extremely slow" relative to WireGuard and IPsec.[9]
  • IPsec: Kernel-resident on most platforms, "WireGuard and IPsec have both gotten faster, with WireGuard stil edging out IPsec in some cases due to its multi-threading."[9]

Mobile and roaming

  • WireGuard: Silent rekeying on a two-minute timer, cryptokey routing allows endpoint change without renegotiation. Strong mobile support.[2]
  • OpenVPN: Reconnects on network change but can drop on aggressive roaming. Often configured with persistent reconnect.
  • IPsec: IKEv2 with MOBIKE (RFC 4554) handles roaming well. iOS and Android native VPN clients use IPsec/IKEv2 by default.[6]

Firewall and NAT traversal

  • WireGuard: UDP-only, can be blocked by restrictive firewalls.
  • OpenVPN: Can run over TCP 443, disguises as HTTPS, gets through most firewalls.
  • IPsec: UDP 500/4500 with NAT-Traversal (RFC 4306), ESP packets can be blocked by stateful firewalls that do not implement NAT-T.

What "audit history" actually means here

All three protocols have been attacked in the wild. The relevant question is whether the protocol design and the reference implementation have been poked at carefully, and whether the keepers of the code fix what is found.

WireGuard's formal verification work is published and peer-reviewed. The papers listed on the formal verification page are ACCE proofs (Lipp 2018), eCK model proofs (Dowling and Paterson 2018), Noise Explorer ProVerif verification (Kobeissi and Bhargavan 2018), HACL* verification of Curve25519 (Zinzindohoue et al. 2017), and Fiat-Crypto verification of the 32-bit Curve25519 path (Erbsen et al. 2019).[3] That is a level of mathematical scrutiny the other two protocols have not received.

OpenVPN has had a long tail of advisories. The CVE list for OpenVPN includes a TLS-related denial of service (CVE-2014-* era), the control channel authentication issue (CVE-2018-* era), and a series of issues around the data channel parsing. OpenVPN Inc. has historically been responsive, but the surface area is what it is.

IPsec has had its own issues, including vulnerabilities in IKEv2 implementations (strongSwan, Libreswan, and various vendor stacks have all had CVEs). The protocol itself is fine; the implementations are where the bugs live, and IPsec has more lines of implementation than the other two combined.

Which one you should actually pick

If you are a regular person running a VPN client on your laptop or phone to keep your ISP from logging your DNS or your coffee shop WiFi from snooping: use WireGuard. Every reputable consumer VPN provider now offers WireGuard by default, and the configuration files are a few lines of text. WireGuard is the right answer for speed, battery life, and modern cryptography.[1][2][8]

If WireGuard is blocked by the network you are on (some corporate firewalls and some hotel captive portals block UDP, which kills WireGuard), switch to OpenVPN over TCP 443. It will be slower. It will work.[4]

If you are connecting two offices, or an office to a cloud VPC, or you need a gateway-to-gateway tunnel with hardware acceleration on a firewall appliance: use IPsec with IKEv2. It is the standard, every vendor supports it, and the operational tooling exists. Do not write your own IPsec stack; configure one of the existing ones (strongSwan, Libreswan, the appliance's built-in daemon).[5][6]

If you are building a custom VPN for embedded hardware or a constrained device where you cannot run a kernel module and cannot run OpenSSL, evaluate WireGuard's userspace implementation (wireguard-go) and OpenVPN's small build against the platform's actual constraints. There is no universal answer here.

What you should not do: stick with OpenVPN because it is what your VPN provider set up by default in 2018, or use IPsec because a YouTube tutorial said to. Pick the protocol for the situation, then verify the configuration.

How to verify your own VPN protocol

Three quick checks work for any of the three protocols:

  1. Read your config. For WireGuard, you should see exactly one cipher suite. For OpenVPN, you should see AES-256-GCM or ChaCha20-Poly1305, never AES-CBC or 3DES. For IPsec, your phase 2 proposal should list AES-GCM or ChaCha20-Poly1305 with a SHA-256+ integrity algorithm.[10]
  2. Check the handshake. Use Wireshark to capture the initial handshake. A WireGuard handshake is a 148-byte UDP initiator message under the Noise_IK pattern.[2] OpenVPN handshakes start with a TLS ClientHello. IPsec starts with an IKE_SA_INIT (ISAKMP) exchange on UDP 500 or UDP 4500 with NAT-Traversal.[6]
  3. Look for the vendor's audit report. A reputable VPN provider publishes the date and scope of their last independent security audit. If the audit is older than 18 months, treat the protocol and configuration claims as unverified.

None of these checks turn a misconfigured VPN into a secure one. But they catch the most common failure mode: a default configuration that has not been touched since deployment.

Sources

  1. WireGuard: Introduction (official project page, accessed 2026-09-14). Verbatim: "WireGuard is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPsec, while avoiding the massive headache. It intends to be considerably more performant than OpenVPN."
  2. WireGuard: Protocol & Cryptography (official project page, accessed 2026-09-14). Verbatim on the cipher suite: "ChaCha20 for symmetric encryption, authenticated with Poly1305, using RFC7539's AEAD construction," "Curve25519 for ECDH," "BLAKE2s for hashing and keyed hashing, described in RFC7693," "SipHash24 for hashtable keys," "HKDF for key derivation, as described in RFC5869," with handshake on Noise_IK.
  3. WireGuard: Formal Verification (official project page, accessed 2026-09-14). Lists Tamarin verification (Donenfeld and Milner), ACCE proof (Lipp), eCK model proof (Dowling and Paterson), Noise Explorer / ProVerif (Kobeissi and Bhargavan), HACL* (Zinzindohoue, Bhargavan, Protzenko, Beurdouche), and Fiat-Crypto (Erbsen, Philipoom, Gross, Sloan, Chlipala).
  4. OpenVPN Community: Why OpenVPN (official project page, accessed 2026-09-14). Background on the protocol's flexibility, TLS-based key exchange, and the role of OpenVPN as a TCP-portable fallback.
  5. IETF RFC 4303: IP Encapsulating Security Payload (ESP) (Kent, March 2005, Standards Track). Verbatim: "ESP can be used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality."
  6. IETF RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2) (Kaufman, Hoffman, Nir, et al., October 2014, Internet Standard). Obsoletes RFC 5996 and clarifies IKEv2 requirements over RFC 4306.
  7. Linux Kernel Newbies: Linux 5.6 release notes (accessed 2026-09-14). Documents WireGuard's inclusion in the mainline kernel for the 5.6 release (March 2020).
  8. Mullvad Help: Why WireGuard (vendor help page, accessed 2026-09-14). Verbatim: "WireGuard is written with less than 7,000 lines of code whereas IPSec contains 400,000 lines," and "we don't expect the creator of WireGuard to have written code that contains 100 times more vulnerabilities than IPSec or OpenVPN."
  9. OpenVPN Community: Why OpenVPN - Performance section (official project page, accessed 2026-09-14). Verbatim: "WireGuard and IPsec have both gotten faster, with WireGuard stil edging out IPsec in some cases due to its multi-threading, while OpenVPN remains extremely slow." The page also flags its own benchmarks as outdated.
  10. IETF RFC 8247: Algorithm Implementation Requirements and Usage Guidance for IKEv2 / IPsec (Nir, Kivinen, Wouters, Migault, September 2017, Standards Track). Updates RFC 7296 algorithm requirements. AES-CBC MUST; AES-GCM and ChaCha20-Poly1305 SHOULD; DES MUST NOT.