Why your IPsec tunnel works until the first CHILD SA rekey

The tunnel came up, the ping answered, and everybody signed off. Four hours later the session drops, the peers log a proposal or key-exchange error, and the first guess is that something changed on the network. Nothing changed. A tunnel that carries traffic has proved that the two peers agree on how to authenticate and how to protect the first child association, and it has proved nothing about the key exchange they will demand at renewal. The mismatch sits in the gap between those two events.

Connected does not mean the PFS settings agree

With IKEv2, the first child association is created during the authentication exchange, and its keys are derived from material the IKE association already produced. No separate Diffie-Hellman exchange happens for that child, so a policy that requires one at renewal is not exercised at bring-up.

Renewal is a different exchange. When a child association is rekeyed, the peers may perform a fresh key exchange with the group named in their proposals, and that is the first moment the group settings are compared. Two peers that disagree can therefore authenticate, install a child association and pass traffic, then fail the rekey.

Where the mismatch hides in the proposal string

In strongSwan the group is appended to the child proposal, which is why a string such as aes256gcm16-prfsha256-ecp256 looks like an encryption choice but also carries a key-exchange requirement. A peer that offers only aes256gcm16-prfsha256 has no such requirement, and the two lists intersect on encryption while disagreeing on the exchange.

Read the child proposal and the IKE proposal as separate lists. A group that appears in the IKE list says nothing about the child list, and editing one while reading the other is the usual way this gets missed.

Read the failure, not the file you edited

Find the notify that ended the exchange. A child rekey that returns no acceptable proposal points at the proposal lists; a rekey request that never gets a reply points at the path or at a peer that stopped listening. Those two need different fixes, and the wording of the log line separates them.

Confirm the running configuration rather than the one on disk. A file saved but not loaded, or a connection that was re-read from a different include, will produce a mismatch that no amount of editing the visible file can fix.

Three events that all get called rekey

IKE association rekeying, IKE reauthentication and child association rekeying are separate operations with separate proposal rules. A failure reported at one of them says nothing directly about the others, and a log that mixes them reads like a single recurring fault when it is three.

Note which event the peer names, then check the proposals for that event only. Change one list, reload, and force the same event again. If the log names a reauthentication, the IKE proposal is the one to read. If it names a child rekey, the child proposal carries the group that matters.

Turning renewal off is not a fix

Setting the rekey time to zero suppresses the exchange that fails, and the tunnel then survives until it is torn down or the peer restarts. What you have bought is a longer-lived key and a mismatch that will meet you again during a migration, an audit or a vendor update. The same applies to lifetimes stretched far beyond the policy the other side expects.

Align the proposals instead. Pick a group both peers implement, put it in the child proposal on both ends, and keep the renewal policy inside the range the organisation actually requires.

Prove it with the exchange that failed

Shorten the child rekey time in a maintenance window so the event arrives in minutes rather than hours, or trigger a manual child rekey. Then watch for a successful renewal and confirm traffic continues through it, because a new handshake that installs a child association but drops the application flow is a different defect.

Restore the normal lifetime afterwards and keep both event records, the failing one and the successful one. The proof you want is that the connection survives its own lifecycle, not that it survived a ping.