What goes into an IPsec proposal? IKE and ESP fields

IKE starts, both peers advertise AES, and the tunnel still fails with NO_PROPOSAL_CHOSEN. The log names the proposal but not the field that failed to match. A proposal is a complete offer, and one incompatible field invalidates the whole combination rather than just that line. Reading it as a bag of independent algorithm choices is the usual reason the mismatch stays invisible.

Two negotiations with separate proposal lists

IKEv2 builds two security associations. The first is the IKE SA, which protects the control exchange itself, and the second is the CHILD SA, which carries your traffic through ESP. Each has its own proposal list, and a peer can accept one and reject the other.

That split explains a common confusion: a working IKE SA proves only that the control-channel algorithms matched. If the CHILD proposal fails, the tunnel never carries a packet even though phase one completed and the logs look healthy at the top.

The order inside each list also matters. The responder picks from the initiator's ordered offers, so moving a broadly compatible entry above a narrow one changes which suite gets installed without changing any single algorithm name. Pin that order in configuration rather than relying on defaults. A stable order also makes log comparison between sites meaningful.

Which fields belong to which proposal

The field set is small, but it is not identical across the two negotiations. Read the table by row, because a field in one column may be absent from the other. Syntax varies by implementation; strongSwan's proposal documentation is one concrete reference.

Encryption names the cipher and, in most syntaxes, its key length. Integrity names the hash used to authenticate the ciphertext, and the PRF names the function that derives key material for the IKE SA. The DH group establishes fresh shared secret material, which is why it appears on both sides but for different purposes.

Extended sequence numbers belong only to the data path. They widen the sequence space and are negotiated as part of the CHILD proposal, so a mismatch there rejects a CHILD offer while leaving the IKE SA untouched.

How one complete offer gets selected

Each proposal is a set, and the responder looks for a set where every required field is acceptable. Two lists can both contain AES and SHA-256 and still have no compatible entry, because the key length, the PRF or the DH group differs. The comparison happens per proposal, not per algorithm.

When nothing matches, the responder sends NO_PROPOSAL_CHOSEN with the SA type that failed. Read which proposal list the notify refers to before editing configuration; changing the ESP algorithms when the IKE proposal was rejected wastes a debugging cycle.

Selection behavior is worth knowing when you tune a profile. Some implementations prefer the initiator's order, others reorder by local policy, so a suite that works between two vendors can disappear when you reverse which side starts the connection.

AEAD removes a field rather than adding one

AES-GCM and ChaCha20-Poly1305 authenticate and encrypt in one operation. When either is selected for ESP, the integrity algorithm is not negotiated separately, because the AEAD construction already covers it. A proposal that pairs AES-GCM with SHA-256 is therefore redundant at best and rejected at worst.

The PRF is still separate on the IKE side, since it derives keys for the control channel rather than protecting payloads. That is why an IKE proposal can legitimately combine an AEAD cipher with a PRF and a DH group, while the matching ESP proposal lists only the AEAD cipher and the optional PFS group.

Key length is part of the encryption token, so AES-128-GCM and AES-256-GCM are different offers. A profile copied from a guide that assumed 256-bit keys will not match an endpoint configured for 128-bit ones, even though both lines say AES-GCM. Two peers can agree on the cipher family and still reject each other over the number after the dash.

Read the installed SA, not the configuration

The configured proposal list is an offer; the installed SA is the result. On strongSwan and a Linux kernel, both views are available:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas prints the negotiated algorithms per SA, including whether the CHILD uses AEAD. ip xfrm state shows what the kernel actually installed, which is the place to confirm that a rekey did not fall back to a different suite than the one you documented.

Save that output next to the configuration after a fix. When a client update changes its defaults, the recorded suite gives you a baseline to compare against, and the comparison points at the field that moved instead of restarting the investigation from the top.