EAP or client certificates? Deciding IKEv2 authentication

Your gateway can prove its own identity with a certificate while proving yours through EAP, and that combination is common rather than contradictory. The two mechanisms answer different questions: is this endpoint the one I expect, and is this user or device allowed. Seeing EAP in a profile does not switch server validation off. Reading the profile as a single setting is what sends people to reset the wrong credential.

Decide which claim failed before touching either object. The failure stage tells you, if you read it in order.

Two credentials, two claims

A server certificate binds a name to a key, and the client checks that binding against its trust store. A client certificate binds an identity to a key, and the gateway checks that the presented certificate chains to something it trusts. EAP carries an authentication exchange whose content depends on the method selected. Those are three structures with different lifetimes, different owners and different failure modes.

A passphrase that unlocks a private key is not an account password, even when both prompts appear within seconds of each other. One is local to the device key store, and the other is validated by an authentication server behind the gateway.

EAP is a container, not a method

EAP is a framework: the gateway and the client negotiate a method, and the method decides whether a password, a token, a tunneled inner exchange or a certificate is involved, as the strongSwan IKEv2 documentation sets out. That is why EAP-TLS looks nothing like EAP-MSCHAPv2 from the client's side, even though both appear as EAP in a menu. A profile that names only EAP has not told you what the user will be asked for.

Read the method and the backend together. The backend determines account format, lockout behaviour and what a password reset actually changes, and none of that is visible in the client profile.

The mixed deployment is normal

Server certificate plus EAP for the user is the shape most remote-access gateways deploy, because it gives the client a verifiable endpoint and gives the operator a per-user identity in a central account store. Client certificate deployments exist too, usually where device identity matters more than a password. Both are legitimate, and the mistake is assuming the one you saw last week is the one in front of you.

Ask the operator for the documented method and account format instead of inferring it from field names in a client.

Deciding from the failure stage

Order the observations. A trust error before any user prompt is a server-certificate problem and no password will fix it. A prompt followed by a rejection is a user-authentication problem, with the EAP method and the backend as suspects. A successful authentication followed by a child-SA failure is neither.

Two more distinctions matter. A client that refuses the server certificate usually reports a name mismatch or an unknown authority, which is a trust-store question. A gateway that rejects the user often logs the EAP method and a reason category, which is an account or policy question.

Operating the two models

For certificates the work is issuance, renewal, revocation and lost-device removal, and it happens on a schedule you control. For EAP the work is account lifecycle, method support on each client platform, and whatever second factor the backend requires. Neither model is cheaper in the abstract; they load different teams. Write down which one your deployment actually uses, because the support scripts differ more than the configuration does.

Keep them separate in your notes. A certificate expiry produces a failure on a date, an account lockout produces a failure after a password change, and a method mismatch produces a failure on one platform only.

After identity is accepted

Authentication is one gate. The child security association, the traffic selectors, DNS and the application's own permissions are later gates, each failing on its own terms. An accepted identity that reaches nothing is not an authentication problem.

Record the method, the account or certificate used, and the stage that failed. That note turns the next incident into a lookup instead of an experiment.