VPN Technologies Compared: IPsec vs SSL/TLS vs WireGuard

IPsec operates at the network layer (Layer 3), securing IP packets themselves rather than a specific application session. It's defined across a family of RFCs and consists of two main protocols: Authentication Header (AH), which provides integrity and authentication but no confidentiality, and Encapsulating Security Payload (ESP), which provides confidentiality, integrity, and authentication and is what's used in essentially all real deployments — AH is rarely used alone in practice.

IPsec supports two modes: transport mode, which encrypts only the payload of the IP packet (used for host-to-host protection), and tunnel mode, which encapsulates the entire original IP packet inside a new one (used for site-to-site and remote-access VPNs). Key negotiation is handled by IKE (Internet Key Exchange), now predominantly IKEv2, which establishes the security associations (SAs) that ESP uses.

IPsec's strength is its ubiquity — it's built into essentially every enterprise firewall, router, and OS network stack, and it's the standard for site-to-site VPNs between organizations. Its weakness is complexity: the IKE negotiation process, NAT traversal (NAT-T), and the sheer number of configurable parameters (encryption algorithm, hash algorithm, DH group, lifetimes) create a large surface for misconfiguration and interoperability problems between vendors.

SSL/TLS VPNs (the naming persists even though the underlying protocol is virtually always TLS today, not SSL) operate at a higher layer, typically tunneling traffic over a standard TLS connection on port 443. This gives them a major practical advantage: TLS on 443 traverses nearly any firewall or proxy without special configuration, since it's indistinguishable at the network level from ordinary HTTPS traffic.

There are two common flavors: clientless SSL VPN, which proxies specific web applications through a browser with no client software required, and full-tunnel SSL VPN (via a client like OpenVPN or a vendor's agent), which routes all or a defined set of the client's traffic through the tunnel similarly to IPsec tunnel mode. The tradeoff for firewall-friendliness is typically lower throughput than IPsec at comparable settings, since encapsulating IP or Ethernet frames inside a TLS/TCP stream adds overhead and can trigger TCP-over-TCP performance problems on lossy links.

WireGuard takes a fundamentally different design philosophy: instead of negotiable cipher suites, it hard-codes a single modern cryptographic suite, which drastically reduces both the code size (it's a small fraction of the size of the IPsec or OpenSSL codebases) and the configuration surface area for mistakes.

Its cryptography: Curve25519 for key exchange, ChaCha20 for symmetric encryption, Poly1305 for message authentication, BLAKE2s for hashing, and the Noise protocol framework for the handshake. This is a deliberate departure from AES-based suites — ChaCha20-Poly1305 is fast in software even without AES hardware acceleration, which matters on lower-power devices and mobile clients.

WireGuard runs over UDP, uses static public keys per peer (conceptually similar to SSH host keys) rather than a certificate hierarchy, and treats connections as cryptokey routing — an interface associates a peer's public key directly with the IP ranges it's allowed to source traffic from. It has no built-in support for negotiating cipher suites, which is a security feature, not a limitation: there's no downgrade attack surface because there's nothing to downgrade.

The table below summarizes the architectural and cryptographic differences covered above.

A minimal WireGuard peer configuration illustrates how compact the protocol's surface area is compared to an equivalent IKEv2/IPsec profile:

[Interface]
PrivateKey = <server-private-key>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
# remote client
PublicKey = <client-public-key>
AllowedIPs = 10.99.0.2/32
PersistentKeepalive = 25

• •Assuming WireGuard is a drop-in IPsec replacement for every use case — it lacks IPsec's mature support for complex multi-vendor site-to-site interop and doesn't have a built-in equivalent to X.509-based enterprise PKI identity out of the box (though it's commonly wrapped by orchestration layers that add this)
• •Deploying IPsec with weak legacy defaults left over from old configs — DES/3DES, MD5, or Diffie-Hellman Group 2 — because they were never explicitly upgraded when the appliance was replaced
• •Full-tunnel SSL VPN misconfigured as split-tunnel (or vice versa) without a deliberate risk decision — split-tunnel remote-access VPNs can turn a home network into a bridge into the corporate network if not carefully scoped
• •Treating any of these protocols as sufficient on their own for zero-trust-style access — a VPN establishes an encrypted, authenticated network path; it is not a substitute for per-application authorization

• •Site-to-site between different vendors' firewalls, or where regulatory/compliance frameworks specifically call out IPsec: IPsec remains the interoperable standard
• •Remote access to specific internal web applications without installing client software, or where strict outbound firewalls only permit 443: SSL/TLS VPN
• •New remote-access or overlay-network deployments where you control both endpoints, performance and simplicity matter, and roaming (laptops moving between networks) is common: WireGuard is generally the strongest default choice today