iOS IKEv2 to strongSwan: no proposal chosen, fix the list

The iPhone brings the tunnel up, the gateway answers with nothing, and the phone offers a generic failure. strongSwan's log is more specific: no proposal chosen. That message means the two lists of acceptable cipher suites never overlapped, so the exchange ended before authentication began. It is a matching problem, and the fix is to make the lists intersect.

Where the gateway states its policy

strongSwan writes its policy in the configuration, and the trailing exclamation mark decides how that policy is read. With the mark the list is exhaustive: those entries and nothing else will be accepted. Without it the same line is a preference order, and the daemon may pick something you did not intend. Ask which form is deployed before you translate anything, because the two behave differently against the same client. Record the exact line, mark included, and test against that.

A client offering a wider list can still connect to a pinned gateway, as long as one combination appears on both sides. What cannot happen is negotiation outside the pinned set.

That is why a profile copied from another VPN app may work where yours does not: the other app shipped a different list.

The names have to match, not improve

Two translations catch people moving values from strongSwan into iOS. The integrity algorithm written SHA1 in an IKE proposal travels in its truncated form, which iOS names .SHA96. The Diffie-Hellman group written modp1024 is group 2, which iOS names .group2. Substituting SHA-256 or group 14 will not negotiate against a gateway that only accepts the older pair. The client has to describe the same algorithm, not a stronger one.

Set those values in NEVPNProtocolIKEv2 explicitly. Defaults may be wider or narrower than the profile you are replacing, and the difference only shows up when the handshake fails.

The child proposal fails later and quieter

Configure the child security association as well as the IKE one. When only the IKE parameters line up, the tunnel authenticates and then carries no traffic, which is a much quieter failure than a refusal. Set the child encryption, integrity, group and lifetime in the same pass. Keep the client lifetime at or below the gateway value, since insisting on a longer one produces the same no-proposal-chosen message from a different cause. A mismatch there looks identical to an IKE mismatch in the log.

Check whether the profile authenticates with certificates or a shared secret while you are in the configuration. A proposal rejection and an authentication rejection appear on different lines, and fixing the wrong one costs a day. Test with a fresh connection after each change, one variable at a time, because cached state hides which parameter moved.

Leave the legacy suite only while it is needed

Pinning SHA-1 with a 1024-bit group is a bridge, not a destination. Both are deprecated, and newer clients may refuse them outright, which means the profile will fail on the next device with no change on your side. Treat the pin as temporary and say so in the record.

If strongSwan is yours, add a modern proposal and let both ends negotiate upward while the legacy entry stays for older devices. Read the daemon's status output to see which suite each connection actually used. Then remove the client-side pinning once the modern pair is confirmed. A tunnel that comes up is not enough evidence, because it can come up on the suite you were trying to retire. The strongSwan IKEv2 documentation describes the proposal syntax and the strict marker.