The name is confusing before you start, because two protocols share the job and people use the words interchangeably. IPsec is the part that carries data. IKEv2 is the part that agrees on keys. They are specified separately, implemented in different places, and fail in different ways.
The data plane: ESP
IPsec offers two packet formats. AH, the Authentication Header (RFC 4302), authenticates a packet without encrypting it. ESP, Encapsulating Security Payload (RFC 4303), authenticates and encrypts. In practice essentially every deployment uses ESP alone, because a tunnel that proves authenticity while publishing the contents is a narrow product.
ESP runs in one of two modes. In transport mode the original IP header stays visible and only the payload is protected, which suits two hosts talking directly. In tunnel mode the entire original packet, header included, is encrypted and wrapped in a new one addressed to the gateway. Tunnel mode is what people mean by a VPN: the outer header says "traffic between my phone and the gateway" and the inner one, which nobody on the path can read, says where the traffic is really going.
A crucial detail for anyone reasoning about metadata: the outer header is not protected and cannot be. Routers need it. So an observer on the café Wi-Fi learns that your device is speaking IPsec to a particular gateway address, plus packet sizes and timing, which is the same residual exposure every tunnel leaves. This is worth keeping in view when reading what a VPN does and does not do.
The control plane: two round trips
IKEv2 (RFC 7296) is the negotiation that produces the keys ESP uses. It is deliberately compact. A working tunnel takes two exchanges.
IKE_SA_INIT is the first. Both sides send a Diffie-Hellman public value, a nonce, and their supported algorithms. At the end of this exchange they share a secret and can encrypt, but neither knows who the other is. Everything in this exchange travels in the clear, which is why the identities are not in it.
IKE_AUTH is the second, and it is encrypted under the keys just derived. Each side sends its identity and proves it, then negotiates the first Child SA, which is the actual ESP tunnel that will carry traffic. Authentication can be a certificate signature, a pre-shared key, or EAP, which is how enterprise deployments hand off to an existing directory or a token, and how a phone can authenticate with a username and a certificate at the same time.
That ordering is a real design property and not an accident. Because identities move only after the unauthenticated key exchange completes, a passive observer does not learn who is connecting. It gives IKEv2 identity protection that early IPsec key exchange lacked.
Later, CREATE_CHILD_SA handles rekeying and additional tunnels. If the configuration enables it, a rekey performs a fresh Diffie-Hellman exchange rather than deriving new keys from the old secret, which is what gives the tunnel forward secrecy across its own lifetime. Compromising today's key material does not retroactively open last week's captured traffic.
Forward secrecy on rekey is an option, not a default in every implementation. Look for the PFS or "DH group" setting in the child SA proposal. If it is absent, rekeys derive from the existing secret and a single key compromise reaches back over the whole session.
Why it holds up on a phone
Two extensions explain why mobile operating systems settled on IKEv2 rather than something newer.
NAT traversal. ESP is its own IP protocol number, and home routers and carrier NATs frequently mishandle anything that is not TCP or UDP. IKEv2 detects a NAT on the path during IKE_SA_INIT and moves the whole conversation to UDP port 4500, encapsulating ESP inside UDP (RFC 3948). Without this, IPsec would be unusable on most consumer networks.
MOBIKE (RFC 4555) lets an established tunnel change its outer addresses without renegotiating. When your phone walks out of the building and drops from Wi-Fi to cellular, the IP address changes but the security association survives: the client tells the gateway the new address over the existing encrypted channel, and traffic continues. Your SSH session does not die. This is the same machinery that keeps Wi-Fi Calling attached to a carrier gateway as you move.
Against WireGuard
The obvious comparison is WireGuard, which is the protocol most privacy-focused providers now lead with.
| IKEv2 / IPsec | WireGuard | |
|---|---|---|
| Algorithm choice | Negotiated, wide menu | Fixed set, no negotiation |
| Codebase size | Large; many years of accumulated options | Small enough to read in an afternoon |
| Misconfiguration risk | Real; weak proposals are still expressible | Low; there is little to get wrong |
| Enterprise authentication | Certificates, EAP, directory integration | Static public keys, external tooling needed |
| Network roaming | MOBIKE | Endpoint updates on any authenticated packet |
| Built into stock iOS and Android | Yes | App required |
The negotiation row is where the real trade-off sits. Algorithm agility is why IKEv2 can adopt a new primitive without a new protocol, and it is also why a deployment can be configured into weakness while every component reports success. WireGuard removed the choice deliberately and accepted that upgrading means a new version.
The Diffie-Hellman group problem
The most instructive failure in IPsec's history is a configuration default rather than a broken algorithm. In 2015 the Logjam paper, by Adrian and colleagues, examined how much of the internet performed Diffie-Hellman over a small number of standardised 1024-bit groups. Because the expensive part of the relevant attack depends on the group rather than on the individual connection, an adversary who invested once in precomputation against a widely used group could then break many individual exchanges cheaply.
The authors noted that IKE was a particularly good fit for this, since a handful of groups were baked into standards and reused nearly everywhere, and argued that it offered a plausible explanation for reports of large-scale VPN decryption capability. The practical response was straightforward: stop using 1024-bit groups, prefer 2048-bit or larger, and prefer elliptic curve groups where available. Any IKEv2 configuration you inherit is worth auditing for exactly this.
The forward-looking version of the same concern is quantum. Two extensions exist: RFC 8784 mixes a post-quantum pre-shared key into IKEv2's key derivation so that a recorded session cannot be opened later by breaking the Diffie-Hellman alone, and RFC 9370 allows multiple key exchanges to be combined in one negotiation, which is the same hybrid strategy now being deployed in TLS. Support varies by implementation, so it is a question to ask rather than an assumption to make.
Where it fits
IKEv2 is an old protocol that aged unusually well, mostly because IKEv2 in 2005 was a deliberate simplification of a first version that had grown unmanageable. It is the right answer when you need certificate or directory-backed authentication, when you need the tunnel to survive a network change, or when you cannot install software on the endpoint. WireGuard is the better answer when you control both ends and want the smallest thing that works.
Neither changes what the tunnel is for. A VPN moves the point at which your traffic joins the open internet, and it moves your trust to whoever runs the far end. That is a useful thing to move, and it is not the same as end-to-end encryption of the content, which stays the job of the application. For the difference between the two, what end-to-end encryption actually protects is the shorter read.