Your IKEv2 SA is up but no child SA exists: read the exchange

IKE says the tunnel is up, the child SA is missing, and both statements can be true at once. An established control relationship is not a data association, and the two objects have separate lifetimes, negotiations and failure modes. Reporting the first as connectivity is how a ticket ends up claiming the tunnel is up while nothing works. Read the association list rather than the connection's summary label, because that list is the only place the missing object is visible. What follows is the order in which the list makes sense.

Two associations, two jobs

An IKE SA carries the control channel: identities, keys and the proposals for the control exchange itself. A child SA carries the ESP protection, with its own algorithms and its own traffic selectors. Authentication and child creation usually travel together, because the first child is negotiated inside IKE_AUTH, and that bundling is exactly why the separation surprises people.

It also explains the two shapes of failure you will meet. A child rejected during the initial exchange normally takes the IKE SA down with it, so you see no established control channel at all. An IKE SA standing alone more often means the first child succeeded and a later create-child attempt failed, during a rekey for instance. Timestamps separate those cases faster than any configuration review.

Which layer refused

When a child is rejected, the notification names the layer. A proposal rejection means the peers could not agree on algorithms, commonly because one requires a different perfect-forward-secrecy group or a cipher the other will not accept. A selector rejection means the traffic set was refused outright, which is a coverage argument rather than a cryptographic one.

Sometimes no child is the design. A childless IKE SA is a defined extension used where the data association should be created on demand, so the absence is correct and the child appears when matching traffic arrives. strongSwan's IKEv2 notes cover both the on-demand style and the proposal settings that decide the first case.

Check for an on-demand or trap configuration before diagnosing a fault. If children are created lazily, no child at idle is the expected state and the real test is whether traffic brings one up. That test also separates a lazy design from a silent failure, since a failed creation leaves the trigger unanswered rather than merely idle.

Then ask about the data path

Once a child exists, the counters answer the next question. ip -s xfrm state reports per-association packet and byte counts, and a child that carries nothing while you generate traffic points at matching or routing rather than at a missing association. swanctl --list-sas prints the child's selectors beside those counters, which is what confirms the packet sits inside the accepted set.

Keep the successful authentication and the failed child exchange separate in the write-up. A report that says authentication failed sends the next engineer to the certificate store, and the accurate sentence is much shorter: the IKE SA came up, and the child for this flow was never accepted.

Correlate the two ends

For a server you run, pull the client and gateway logs for the same exchange rather than comparing two reconnect attempts an hour apart. The notifications should match on both sides, and where they do not, you have found the peer that is misconfigured.

Correct the child negotiation, then retest with traffic inside the intended selector. That is the only test that proves the missing object is now present, because an association list refreshed at idle can look identical before and after the fix.