IPsec vs WireGuard: which VPN protocol should you use?

Short answer

Choose IPsec with IKEv2 if you need to connect equipment from different vendors, rely on the VPN client already built into an operating system, or follow guidance that asks for an open standard. Choose WireGuard if you manage both ends yourself and want a small, readable configuration with no cipher choices to get wrong. Both are open, both are well established on Linux, and both can be secure. The difference is mostly about interoperability versus simplicity.

Side-by-side comparison

Sources: RFCs and project pages listed under Sources, checked October 6, 2026.

Design: a suite versus a single protocol

IPsec is a framework. RFC 4301 describes an architecture with security associations, policies and two modes (transport and tunnel). IKEv2 negotiates which algorithms to use and builds the SAs. ESP then encrypts the packets. That flexibility is why IPsec can link a branch office firewall to a cloud gateway from another vendor, and why its configuration files can grow long. We walk through the pieces in What is an IPsec VPN?

WireGuard takes the opposite approach. Its home page says it is "meant to be easily implemented in very few lines of code, and easily auditable." There is no algorithm negotiation. At its core is what the project calls Cryptokey Routing, "associating public keys with a list of tunnel IP addresses that are allowed inside the tunnel." If a packet arrives from a peer's key, WireGuard checks that the source address is one that peer is allowed to use. If you want to send a packet to an address, the table tells it which peer's key to encrypt to.

What the configuration looks like

This is the clearest way to see the difference. Below is an illustrative WireGuard configuration in the style of the examples on wireguard.com, with placeholders instead of real keys:

# Example only: replace the placeholders
[Interface]
PrivateKey = <private-key>
ListenPort = 51820

[Peer]
PublicKey = <peer-public-key>
AllowedIPs = 10.0.0.2/32

That is a complete peer definition. An equivalent IPsec tunnel needs you to decide on authentication (certificates or a shared secret), IKE and ESP proposals, local and remote identities, and traffic selectors. With strongSwan this goes in swanctl.conf; with Libreswan in /etc/ipsec.conf. None of it is difficult once you know the concepts, but there are more settings, and each one is a chance to mismatch the other side.

Networks, NAT and firewalls

Both protocols use UDP, so both cross home routers and carrier NAT. The details differ.

• IPsec starts on UDP 500. If either side detects NAT, IKE and ESP move to UDP 4500, with ESP wrapped in UDP as defined in RFC 3948. Without NAT, ESP travels as IP protocol 50, which some firewalls drop unless a rule allows it. The Canadian Centre for Cyber Security also warns that "some third-party networks restrict or block IPsec traffic."
• WireGuard uses one UDP port that you choose. It stays quiet when idle; its quick start says "it is not a chatty protocol." A peer behind NAT that must receive traffic while idle can turn on persistent keepalives, for which the documentation suggests 25 seconds as "a sensible interval that works with a wide variety of firewalls."

Neither protocol is designed to hide what it is. WireGuard's documentation states plainly that it "does not focus on obfuscation." On networks that block both, a TLS-based VPN over TCP 443 may be the only thing that gets through; see IPsec vs SSL VPN.

Cryptography and security trade-offs

WireGuard's fixed suite means every WireGuard connection uses the same primitives. You cannot accidentally enable a weak cipher, and you cannot negotiate down. If one of those primitives were ever broken, the protocol would need a new version rather than a configuration change.

IPsec negotiates. That allows you to follow current guidance, such as RFC 8221's requirement for AES-GCM, and to meet policies that ask for specific validated algorithms. It also means an old peer can drag a tunnel down to weak settings if you allow them. The Cyber Centre points organizations to its network protocol configuration guidance (ITSP.40.062) for IPsec and TLS settings.

Two WireGuard limitations from its own documentation are worth knowing:

• "WireGuard is not, by default, post-quantum secure", although an optional pre-shared key can add a layer of post-quantum protection.
• WireGuard's handshake does not fully hide identities from someone who later obtains a responder's private key and has old traffic logs, as the known-limitations page explains in its section on identity hiding.

Which one to use, case by case

Company remote access

IPsec with IKEv2 is the conventional choice, and it is the one the Canadian Centre for Cyber Security recommends "as a primary consideration" for VPN access. Staff can often use the operating system's own client, and certificate or EAP authentication fits existing identity systems.

Linking two offices or an office to the cloud

If the devices at each end are from different vendors, use IPsec. If you control both ends and both support WireGuard, WireGuard is quicker to set up and easier to read later.

Home lab, personal server or a few devices

WireGuard is usually the easier path. Generate a key pair per device, exchange public keys, set the allowed IPs, and you are done. If you would rather not manage keys by hand, tools built on WireGuard can do it for you; see the Tailscale section in WireGuard vs OpenVPN.

A router that protects the whole household

Check the firmware. Our VPN router guide explains what to look for. Where both are offered, WireGuard is normally simpler to configure on a router, while IPsec is the better fit if the router must connect to an office gateway.

A consumer VPN app

Here the provider has already made most of the decisions. If the app offers a choice of WireGuard (or a variant of it), OpenVPN or IKEv2, any of them is fine. Switch if one does not connect on a given network. Our VPN protocols guide covers the options by device.

Software to look at

• WireGuard: kernel module on Linux (mainline since 5.6); the installation page lists Windows, macOS, Android, iOS and OpenWRT among others.
• strongSwan: IKEv1 and IKEv2 daemon, configured with swanctl, GPLv2.
• Libreswan: IKEv1 and IKEv2, uses the kernel's XFRM stack and the NSS crypto library, GPLv2.

For how the two IPsec projects differ, read strongSwan vs Libreswan.

Common questions