IKEv2 is not one handshake: IKE SA, auth, then CHILD SA
A gateway answer proves reachability, not identity. Follow IKE_SA_INIT, IKE_AUTH and the first CHILD SA, then check what must be true before traffic flows.
You may think an IKEv2 connection is one exchange that ends with your traffic encrypted. It is at least two, and the first one does not authenticate anybody. The peers start with control messages, agree on cryptographic parameters, prove identity, and only then negotiate the state that carries application packets. That ordering explains the mismatch people report constantly: the gateway answers, the client says connected, and the private application still times out. Here is what each stage actually does, and what has to be true after it.
The myth: if the gateway answers, you are connected
A response to the first message proves the endpoint is reachable and willing to talk. It does not prove that an account was accepted, that a certificate chain validated, or that any data policy was installed.
Those failures happen later, and they produce different symptoms. A certificate rejection or an EAP failure arrives after the first exchange has already succeeded, which is why a ping to UDP 500 and a green client icon tell you so little.
IKE_SA_INIT: agree on parameters, not identity
The first exchange carries proposals for the IKE security association: encryption and integrity algorithms, a pseudorandom function, and a Diffie-Hellman group. The peers also exchange nonces, and each side derives key material for the IKE SA from the shared secret those values produce. Nothing in this exchange establishes who the other party is. It establishes that both sides can compute the same keys and that they agree on a proposal. A responder that does not like any proposal rejects the exchange here, which is why a version or algorithm mismatch looks like the server being down.
The IKE SA created at this point protects all later management exchanges. That is its job, and it is a different job from protecting your packets.
IKE_AUTH: prove identity, then build the first CHILD SA
The second exchange carries identity. With certificates, each peer signs with its private key and presents a chain the other must validate; with EAP, the responder challenges the initiator through the chosen method. This is where a wrong server name, an expired certificate or a rejected password finally surfaces.
In the normal case IKE_AUTH also negotiates the first CHILD SA, so the data protection is agreed in the same round trip. The initiator proposes traffic selectors, the responder narrows or rejects them, and keys for the data path are derived from the IKE SA. That means a single exchange can fail in two very different places: identity, or policy. Read the notify payload or error rather than the generic handshake failure, because the fix for one is a certificate and the fix for the other is a subnet mismatch.
Two SAs, two jobs
| Association | Protects | Lifetime behaviour |
|---|---|---|
| IKE SA | Management exchanges: rekeying, delete, configuration payloads | Rekeyed on its own schedule; the data path can survive the change |
| CHILD SA | Application traffic matching the traffic selectors | Rekeyed independently, often more frequently |
Keeping them apart explains two behaviours that look like bugs. A tunnel can show established while a rekey is failing in the background, and a CHILD SA can be replaced without the client dropping the connection.
On strongSwan, the IKEv2 configuration reference and swanctl --list-sas show both levels, and ip xfrm state plus ip xfrm policy show what the kernel actually installed. Comparing those two views is the fastest way to see whether the negotiation finished or only looked finished. If the daemon lists a CHILD SA that the kernel has no state for, the install failed quietly. If the kernel holds state the daemon does not know about, you are looking at a leftover from an earlier attempt.
What still has to be true after the tunnel is up
Traffic selectors define which addresses are covered. If the client proposes one subnet and the server expects another, the CHILD SA installs but carries nothing useful, and the error appears as a routing problem rather than a negotiation problem. Then the local stack has to cooperate: forwarding enabled where the host routes, routes pointing at the tunnel, firewall rules permitting the decapsulated packets, and an internal resolver if private names are involved. Each of those fails separately and none of them is fixed by restarting the IKE daemon.
Keep the log visible while you diagnose: the initial exchange, then identity validation, then user authentication where that applies, then CHILD installation, then application traffic. The stage that stops is the stage to fix, and a later routing failure is never a reason to relax the identity checks that already passed.