IKEv2 Exchange Works, Then Authentication Fails: Where

A client that receives an IKEv2 response has proved that the gateway is reachable, that both sides can negotiate a proposal, and that the initial key exchange completed. It has not proved that anyone is authenticated. The next exchange carries identities, certificates or EAP, and that is where the connection usually stops. Reading which of those checks failed is the whole diagnosis, and the error message alone rarely says.

Check 1: read the stage, not the message

There are three places a rejection can come from: the client refusing the server's identity, the gateway refusing the client's proof, and an external authentication service refusing the account.

Each produces a different log line on a different machine, and each has a different fix. A client-side rejection of the server certificate is a trust or naming problem on the client; a gateway-side rejection of the client certificate is a trust problem on the gateway; an EAP failure is an account or backend problem. The message you see is usually the client's summary of one of those, which is why the gateway log matters as much as the client's.

Check 2: which identity was checked

A client can reject the server's certificate or its expected identity before any user credential is offered, and a working server address is not a substitute for that check. The identifier the client expects must match what the gateway presents, which is a configuration fact rather than a network one.

In strongSwan terms that is rightid on the client and the gateway's own identity on the other side, and a mismatch fails before EAP is even discussed.

The gateway, separately, can reject the client's certificate, its key proof or its account authentication, and those three are not interchangeable. Resetting a user password cannot renew a device certificate, and reinstalling a device certificate cannot fix a wrong server identity. For certificate failures, check the clock first, then the trust chain, then the expected identifier; a client whose clock is minutes off fails a validity check that looks like a trust failure. swanctl --list-certs on both ends shows what each side actually holds.

Check 3: if EAP is in play

The client and the server have to agree on a supported method, and the backend has to accept the identity that is supplied.

A username may need a domain suffix or a specific account format that the deployment requires, and the format is documented rather than guessable. Supplying the operator's documented fields is faster than trying variations, and it avoids a second problem: repeated attempts can trip an account lockout, which then hides the original stage behind a new failure. If the method is EAP-MSCHAPv2 against a directory, the failure may belong to the directory rather than to the VPN at all.

Do not test identity problems by disabling identity checks. That converts a diagnosable failure into an undiagnosable one and leaves the connection weaker than before.

Check 4: what happens after a successful login

Once IKE_AUTH completes, CHILD_SA negotiation decides which traffic selectors are installed, and that is where a connection can succeed and still pass nothing.

A newly working login often reveals a selector or route problem that was previously hidden behind the authentication failure. If the tunnel comes up and an application still cannot reach its destination, look at the negotiated selectors and the routes rather than at identity again. Changing identity settings at that point targets the wrong stage and usually breaks a working login. Confirm with swanctl --list-sas, which shows the children and their selectors separately from the IKE SA.

Check 5: what to hand to support

A sanitised timeline and the precise rejection are worth more than a full diagnostic export, and the export may contain private keys or credentials you should not be sharing.

Record the time with the time zone, the client and gateway versions, the method, the identity string that was offered rather than the password, and the exact stage that rejected it. The strongSwan IKEv2 configuration documentation describes the identity and EAP settings that decide these outcomes, and it is the reference to read before changing a field. Then change one thing and re-test a fresh connection, because a cached session will tell you about the old configuration.