Key takeaways

  • WireGuard uses a fixed set of primitives (Curve25519, ChaCha20-Poly1305, BLAKE2s, HKDF) and a Noise IK handshake over UDP. There is no algorithm negotiation, which removes a class of downgrade problems and also means a change needs a new protocol version.
  • IPsec uses IKEv2 (RFC 7296) to authenticate the peers and negotiate Security Associations, then ESP (RFC 4303) to protect traffic. It supports certificates, pre-shared keys and EAP, and many cipher suites such as AES-GCM (RFC 4106).
  • Key management is the real difference. WireGuard peers exchange public keys out of band, and the rest is configuration. IPsec can use a certificate authority, which scales well and demands a PKI process.
  • For meshes, routing matters. WireGuard's cryptokey routing ties each peer to a list of allowed IPs. IPsec policy uses traffic selectors, or routed tunnel interfaces, with BGP or OSPF on top. Both need a routing design.
  • Performance depends on hardware, cipher and implementation. The WireGuard project's own comparison is old, and it says so. Measure on your hardware with your traffic, and check whether AES hardware acceleration is present before choosing a cipher.
  • Interoperability is IPsec's strength: firewalls, cloud gateways and routers from many vendors speak it. WireGuard is easy on Linux and increasingly common elsewhere, but check support on any appliance you must keep.

The question

A company with a few offices and a few cloud networks needs them to behave as one private network. The traffic crosses the public internet, so it must be encrypted and authenticated. Two answers dominate: IPsec, which has been the standard answer for decades, and WireGuard, a newer protocol that is much smaller. Both are sound choices. The better one depends on what the mesh must connect to, who operates it, and how many sites it will have.

How WireGuard works

WireGuard's design is documented on the project's protocol page and in its whitepaper. It uses a fixed set of primitives: ChaCha20‑Poly1305 for authenticated encryption, Curve25519 for key agreement, BLAKE2s for hashing, SipHash24 for hash-table keys and HKDF for key derivation. The key exchange is based on the Noise IK pattern, with an optional pre-shared key that adds a layer of symmetric protection. Everything runs over UDP.

The handshake is two messages: an initiation and a response, which is one round trip. The responder does not send session data until the initiator confirms the session, so an initiator with nothing to send sends an empty packet. Handshakes repeat on a timer so that keys rotate regularly for forward secrecy, and the timing does not depend on traffic. A peer that has not authenticated gets no answer: the project page says the server stays silent toward unauthenticated clients and keeps no state for them. When a server is under load it can reply with a cookie, which the client must echo in a second MAC; cookies expire after two minutes and are tied to the sender's address. A 64‑bit counter and a sliding window (about 2,000 values) protect against replay while tolerating reordering.

The idea that makes WireGuard approachable is cryptokey routing. Each peer's public key is associated with a list of tunnel IP addresses. When sending, that list works like a routing table that picks the peer for a destination. When receiving, it works like an access list: a decrypted packet is accepted only if its source address belongs to the peer that sent it. Roaming is built in. Each side sends to the latest endpoint that produced valid traffic, so an address change does not break the tunnel. The code lives in the Linux kernel, which the project credits for its speed, and implementations exist for Windows, macOS, BSD, iOS and Android.

How IPsec works

IPsec is a family of protocols, and the modern profile has two main parts. The Internet Key Exchange, IKEv2 (RFC 7296), authenticates the two peers and sets up Security Associations. It normally uses UDP port 500, and moves to port 4500 when NAT is detected. A common setup takes four messages: the IKE_SA_INIT exchange negotiates algorithms, swaps nonces and does a Diffie-Hellman exchange, and the IKE_AUTH exchange authenticates the peers and creates the first child SA. CREATE_CHILD_SA adds or rekeys SAs, and INFORMATIONAL exchanges handle deletes, errors and liveness checks. Authentication can use certificates, shared secrets or EAP. Proposals list transforms the peers can use, and the two sides choose a mix. Traffic selectors say which traffic each child SA protects.

The Encapsulating Security Payload, ESP (RFC 4303), then protects the data. ESP is its own IP protocol, number 50. Each packet carries a 32‑bit Security Parameters Index that identifies the SA, a sequence number for anti-replay, the encrypted payload, padding, and an integrity check value. In tunnel mode ESP protects the whole inner IP packet, which is the mode used between sites. RFC 4303 requires integrity-only and combined confidentiality-plus-integrity services, and supports combined-mode ciphers. AES-GCM (RFC 4106) is the common one: it takes a key of 128, 192 or 256 bits, an 8‑byte explicit IV and a 4‑byte salt, and requires support for a 16‑byte integrity value. Where NAT is in the path, RFC 3948 wraps ESP in UDP on port 4500, with small keepalive packets to hold the NAT mapping open.

NIST's Guide to IPsec VPNs, SP 800-77 Revision 1 (June 2020), is a good neutral reference for selecting and configuring IPsec, including IKE. It also covers alternatives and when each may fit.

Key management: where the two diverge

WireGuard's key model is deliberately simple. Each endpoint has a key pair. You give each peer the other's public key, together with the allowed IPs and, for the dialing side, an endpoint. There is no certificate authority and no negotiation. For a mesh of ten sites, that is a manageable list. For a mesh of hundreds, it is a configuration management problem, and teams solve it with automation that generates and distributes configuration from a source of truth. Key rotation, revocation (remove the peer) and onboarding are done by that automation, not by the protocol. WireGuard also has no built-in user authentication such as EAP, so it suits site-to-site and device-to-site use more than a login-driven remote access service.

IPsec's key model is richer. With a certificate authority, each gateway gets a certificate, peers verify each other against the CA, and revocation works through the CA's usual mechanisms. That scales cleanly and fits organizations that already run a PKI. It also means you operate that PKI. Pre-shared keys are simpler, but they do not scale, and each pair needs its own strong secret. IKEv2 can also rekey and renegotiate algorithms without taking the tunnel down, and can use EAP for user authentication. The cost is complexity: a larger configuration surface and more ways to mismatch two ends.

Crypto agility versus a fixed design

IKEv2 negotiates. Both ends propose transforms and agree on a suite, so IPsec can move to new algorithms without a new protocol, and so a weak proposal can still be configured by mistake. WireGuard has no such negotiation: the primitives are fixed in a protocol version. The advantage is that there is no downgrade path and little to misconfigure. The disadvantage is that a future change needs a new version on both ends, and a regulator that requires a specific algorithm (for example one approved for a particular government use) may not accept ChaCha20‑Poly1305 or Curve25519. If you are subject to such requirements, check them first, because they may decide the question before performance does.

NAT, roaming and failure behavior

Both protocols work behind NAT. IPsec uses UDP encapsulation on port 4500 and NAT keepalives. WireGuard is UDP only and sends keepalives when you ask it to (the persistent keepalive option) so a NAT mapping stays open. WireGuard roams naturally, because the peer endpoint is updated from authenticated traffic. IPsec can handle address changes with MOBIKE, an IKEv2 extension, but both gateways must support it.

On failure, WireGuard is stateless between handshakes. A restarted peer simply handshakes again. IPsec has a more explicit session life cycle with liveness checks (an empty INFORMATIONAL request) and SA lifetimes, and it can be tuned for fast failover. For both, failure detection for routing should be done at the routing layer, with BFD or a routing protocol keepalive over the tunnel, not left to the VPN.

Routing a mesh

A full mesh of N sites has N(N-1)/2 tunnels, so ten sites need 45 and fifty sites need 1,225. Most real designs avoid a full mesh. A hub-and-spoke design sends spokes through one or two hubs. A partial mesh places tunnels where the traffic is. A dynamic design lets spokes set up direct tunnels on demand.

With WireGuard, the allowed-IPs list is both routing and access control, which is elegant for small meshes and awkward when you also run a dynamic routing protocol, because the protocol's learned routes must fit within the allowed IPs. Many operators set allowed IPs broadly on a point-to-point interface and enforce policy in the firewall and routing layers. With IPsec, you can use policy-based tunnels with traffic selectors, which are simple for a few subnets and cumbersome as they grow, or route-based tunnels with virtual tunnel interfaces, which behave like any other link and carry BGP or OSPF. For anything beyond a handful of sites, route-based design is the usual choice for either protocol. The edge routing techniques we cover in our BGP article apply directly.

Performance, honestly

Claims that one protocol is always faster do not survive contact with hardware. The WireGuard project publishes a performance page, and it is candid: its tests used 2016‑era laptops, Linux 4.6.1, gigabit Ethernet and iperf3, compared WireGuard with IPsec using ChaCha20‑Poly1305 and with IPsec using AES-256‑GCM on AES-NI, and the author calls the benchmarks old and not well conducted, noting that all of the protocols have gotten faster since. Treat that as a reminder to test.

The factors that really decide throughput are the cipher and whether the CPU accelerates it (AES-NI favors AES-GCM, and CPUs without it often do better with ChaCha20), where the code runs (kernel, user space or a hardware offload engine on a firewall), the number of cores available and how well the traffic spreads over them, the packet size mix, and the MTU. Both add overhead to each packet, so set the tunnel MTU deliberately and test with large transfers. Some commercial firewalls offload IPsec to dedicated silicon and so reach rates that software tunnels on the same appliance do not. On general-purpose Linux servers, both protocols can fill fast links.

Choosing

  • Choose WireGuard when you control both ends, mostly run Linux or modern clients, want a small and auditable configuration, and can automate key distribution. It is a good fit for cloud-to-cloud, datacenter-to-cloud and engineering-managed meshes.
  • Choose IPsec when you must interoperate with firewalls and cloud gateways from different vendors, when a PKI is already in place, when compliance names specific algorithms, or when you need hardware offload.
  • Use both when it helps. Many organizations run IPsec to a partner or cloud provider that requires it, and WireGuard inside their own mesh. The routing layer ties them together.
  • Whichever you choose, encrypt in addition to, not instead of, segmentation. A tunnel is not a firewall.
  • Plan operations on day one: configuration as code, monitoring of handshake age or SA state, alerts on a tunnel that is up with no traffic, a documented way to rotate keys and to remove a lost device or a retired site.

Our team has built both kinds of meshes, and we usually advise starting from the operational constraints, not from the protocol. If you can describe your sites, carriers, devices and compliance obligations, the right answer is usually clear within an hour. Related reading: MPLS, SD-WAN or EVPN: Choosing a Backbone for a Multi-Site Company; Post-Quantum Encryption in Practice: Hybrid ML-KEM and X25519, FIPS 203.

Sources

This article is general technical information, not a design for your network. Features and defaults differ between implementations and versions, so confirm them on your equipment. Statements about MOBIKE, persistent keepalive, algorithm requirements of particular regulators and hardware offload are general engineering knowledge, not quoted from the sources listed. We read the WireGuard whitepaper PDF link but could not extract its text, so protocol details come from the WireGuard protocol page. Last reviewed .

Keep reading

Need help with this?

One view of your entire cybersecurity program, in near real time.

Clayton Secure