iOS rejected your strongSwan tunnel: compare the IKE proposals

Nothing in the certificate or address explains why an iPhone that connected to strongSwan last year fails this year. Nothing about the address, the pre-shared key or the client identity has to have changed. What moved is the list of transforms the phone's built-in client is prepared to negotiate, and once that list stops overlapping the server's, the exchange ends before anyone's identity is examined.

The log line that decides it

Turn up logging for that connection and find the two entries that decide the outcome: what the phone offered, and what the server picked. If the log ends without a selected proposal and reports that nothing matched, authentication was never attempted. A fresh certificate and a new password change nothing at that point, because both are consumed at a later stage. Neither can influence a result that was decided before identity was examined.

Keep the two failure shapes apart before editing anything. No transform edit will rescue a rejected credential, and no credential fix will rescue a rejected transform. The log entry that names a selected proposal tells you which of the two you are in. Without that entry, you are guessing.

The selected line names the proposal by its transform set rather than a friendly label. Compare the encryption, integrity and group fields in that line with the list the phone sent, because a mismatch in any one field is enough to lose.

What changed on the phone

One iOS release trimmed the algorithms its client is willing to use. Weak integrity hashes, small Diffie-Hellman groups, and proposals that list legacy options first stopped being acceptable.

Longer lists are not safer here. Selection follows the phone accepted set and its own preference order, so a server that advertises a broad catalogue can still lose the negotiation when the modern entries are not the ones that get picked. Prefer a short list with the modern entries first. A long list that opens with legacy options invites exactly the failure you are trying to avoid. The accepted set is an outside constraint that moves whenever the client updates, so yesterday working configuration is evidence about yesterday.

One pair that still negotiates

For current phones a single modern combination is sufficient. One pair that negotiates looks like this:

ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256

The ike line carries the encryption, integrity and Diffie-Hellman group used while the keying exchange runs. The esp line covers only the data channel, because the group was settled before it applies. Reload the connection or restart the daemon, then reconnect the phone. Keep that group value only if every client you serve still accepts it, and do not broaden the proposal for everyone because one old peer needs more.

Three places to fix it, one usually closed

• One modern proposal for every peer. Correct when all clients are current phones and desktops. It deletes the old transforms instead of negotiating around them.
• A second connection definition for Apple clients. Keeps one legacy peer alive while giving the phone a proposal it accepts. It costs another connection block and makes the exception visible.
• Changing the client. Rarely open to you: when a management system or an app ships the profile, there is no proposal editor to touch, and the built-in client does not expose one.

Choose the second option when a device outside your control cannot be updated. Pick the first when you can retire the legacy peer and prefer to carry a single policy.

Either way the choice is visible in the configuration, which is the point. A silent fallback that negotiates down to an old transform is worse than an explicit block, because no review will ever surface it.

Prove it, then record it

Reconnect and check three separate facts on the server: a proposal was selected, the connection shows established, and the client received an address. An established handshake with no remote address points at the pool or the traffic selectors, and it belongs in its own change. Treating the two together makes a solved negotiation look unsolved.

Write down the transform set that was accepted, when you changed it and which client build you verified. The next update can move the requirement again, and the values that worked are the first thing you will want beside the new ones.