Plan IKEv2 Settings That Fit More Than One Client
A working desktop profile has tested one client. Agree the identity contract, pick a supported intersection, then test renewal and sleep per platform.
A working profile on one desktop is a successful test of one client. It is not a cross-platform deployment, and treating it as one produces the familiar support pattern: Windows connects, the phone fails at the identity check, and the managed laptop reconnects every time it wakes. The differences are real and mostly predictable, which is why the plan should be a matrix rather than a screenshot.
Decide the identity contract first
Document the server identity, the certificate trust and the client-authentication method before discussing algorithms. Those three decide whether a client can authenticate at all, and they are the parts platforms express differently.
Check how each platform names the expected identifier and how it handles subject alternative names. A profile that accepts a server name on one client may reject the same certificate on another because the identifier field is populated from a different value.
| Contract element | What to decide | Where platforms diverge |
|---|---|---|
| Server identity | Name or address the client must see | Identifier field and SAN matching |
| Client authentication | Certificate, EAP method or both | Which EAP variants exist and how prompts appear |
| Trust anchor | Which CA and how it is delivered | Store location and provisioning path |
Then choose the cryptographic intersection
Compare the proposals each supported client can offer and pick a modern intersection the gateway also permits. Do not enable an oversized legacy list so one old device connects, because that list becomes the gateway's default for everybody who follows. Write down why each legacy option is still there. If nobody can name the device that needs it, it is not a requirement.
Keep IKE and CHILD settings distinct in the plan. A proposal that is acceptable for the IKE exchange is not automatically acceptable for protected traffic, and the two are negotiated separately. A gateway that accepts a proposal at one layer can still refuse it at the other, and the log will show a failure that looks like the first layer succeeded.
Provision credentials through a verified process, and keep a user password, a shared secret and a client private key in their own fields. Trial and error across similarly named boxes is how a working test becomes an unreproducible one.
Test the lifecycle, not the steady state
For each client, test the initial authentication, the intended application, DNS resolution and address-family coverage. Then exercise the parts that only appear later: renewal, sleep and a normal network change.
MOBIKE support and reauthentication behaviour can differ from the steady-state result you just measured. Record the event and the association state at the time, rather than only whether the interface eventually looks connected.
Define what direct traffic may do while the VPN is unavailable. That is a policy decision separate from whether the client reconnects, and most deployments answer the second question while ignoring the first. Write the answer into the deployment notes next to the profile names. Someone will need it during an outage, and they will not have time to reconstruct it.
Use server identity checks when one platform disagrees
When a profile works on one platform and another rejects its name, compare the identifier the client actually sent with the identifiers the certificate carries. That comparison resolves most of these cases faster than changing cipher lists.
Keep the tested matrix with the configuration source and the update procedure. When support for an old client ends, remove its exception deliberately instead of leaving weaker compatibility settings hidden in the gateway for the next audit to find. The strongSwan IKEv2 documentation is a useful reference for how the exchanges are configured.