IKEv2 NO_PROPOSAL_CHOSEN: Which Stage Rejected the Suite?

NO_PROPOSAL_CHOSEN in a log sends people to the pre-shared key, and the error survives the change. It was never a credential problem: the peer rejected every proposal offered for that exchange, which is a statement about algorithms rather than identity. The first useful question is not which algorithm to edit but which exchange was rejected. Answer that before comparing anything. Then compare the full suite that was offered with the full suite the peer permits.

First: which exchange was rejected

IKEv2 negotiates two kinds of association. The IKE SA protects the negotiation itself, and the CHILD SA protects the traffic. Each has its own proposal set, and each can fail with the same notification. A rejection during initial IKE negotiation and a rejection during CHILD negotiation need different fixes, and the log usually names the exchange a line or two above the notify. Read those two lines together, or you will edit the wrong proposal list.

The notification alone does not identify the exchange. The line above it names the SA being negotiated, and that name points at the proposal list to inspect.

Compare complete suites, not single keywords

A proposal is a combination: encryption algorithm, integrity or AEAD, key-exchange group, and any pseudo-random function. Comparing only the encryption name is the usual mistake, because two peers can agree on AES-256 and still disagree on SHA-1 versus SHA-256. Write the offered and permitted suites side by side at the failed stage, then look for the empty intersection.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

Also check that both implementations support what you configured. A name copied from another platform can look syntactically familiar while the plugin or implementation is missing entirely.

IKE suite and ESP suite are different objects

Editing the IKE proposal will not repair a rejected CHILD proposal, and the reverse is also true. In strongSwan these are separate settings, roughly proposals = aes256-sha256-modp2048 for the IKE SA and a separate ESP list for the CHILD SA. Change the list that matches the failed exchange, then re-read the log rather than assuming the fix worked.

For the CHILD SA, the relevant setting is the ESP proposal list, not the IKE one. Copying the IKE line into it produces a configuration that parses and negotiates the wrong object.

A working tunnel that fails on rekey

If the tunnel ran for an hour and then failed, the initial negotiation is not the problem. A rekey can exercise different conditions: a different key-exchange group after the first exchange, a lifetime mismatch between peers, or a responder policy that changed. Keep the renewal timestamp and the association identifiers from both sides. That pattern needs a proposal comparison at renewal, not a longer timeout. A timeout change hides the symptom and leaves the mismatch in place.

ipsec statusall shows each association and the algorithms actually negotiated. That output is the fastest way to confirm which list was used, and it separates a configuration error from a stale tunnel that never renegotiated.

ipsec statusall | grep -E "IKE:|ESP:"

Choose an intersection, then confirm both phases

Have the administrator pick a documented modern intersection that both peers support, and write it down. Do not solve the error by enabling every legacy algorithm or by disabling identity verification, because neither follows from a rejection. After the change, establish a new connection and then force a rekey. The first connection alone does not prove the renewal path works.

Keep the accepted combination with the firmware versions. If the next error concerns traffic selectors, treat it separately, since agreement on cryptography says nothing about which subnets the tunnel protects. strongSwan's proposal documentation covers the syntax for both lists.