One Error, Three Secrets: Which VPN Credential Failed?
The client shows one error for every stage. Read the association, the user exchange and the method before resetting a password nobody checked.
"Authentication failed" can point at a server certificate, a machine pre-shared key or a user password. Which one it means depends on the protocol, because each protocol defines a different set of secrets. Reset the wrong one and the error survives unchanged. The way out is to establish how many proofs the protocol requires before editing anything.
Two proofs pointing in opposite directions
A tunnel has to answer whether it reached the right gateway, and separately who the user is. The gateway proof is machine-level: a server certificate, a pre-shared key or a static public key. The user proof is person-level: a password, a token, a client certificate, or nothing at all. Those are opposite directions of trust and they consume different material.
IKEv2 performs the gateway proof inside IKE_AUTH and, when EAP is used, runs the user proof in a separate exchange afterwards. The IKEv2 specification keeps those as distinct sections, which is a strong hint about where to look when one message covers both rounds.
Read the stage, not the message
The client shows one error string no matter which stage failed, so the string itself carries almost no information. What carries information is the state you can inspect at each stage: whether an association exists, whether a user exchange started, and whether the client offered the method the gateway wanted. The table sorts the stages that way instead of by protocol name.
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
Only the second row is about a credential a user can retype. The other three are configuration facts, and that mismatch is why so many of these reports end with a password reset that changes nothing. Read the row that matches your evidence before touching a field.
A two-secret protocol shows its hand
L2TP over IPsec makes the count visible, because the two checks happen in different processes. The IPsec layer has to come up first with a pre-shared key or a certificate, and only then does PPP inside it attempt a user login.
When the machine secret is wrong, no association forms and the user credential is never tried. When the machine secret is right and the user secret is wrong, the association exists and PPP rejects the login after the tunnel is already up. Both produce the same message on screen from two different events.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerAn empty association list eliminates the user layer immediately, so check it before the password. An established association with repeated PPP failures points the other way, at the user layer or at the authentication protocol inside it. Neither conclusion is available from the client's error text.
What password-only actually depends on
Password-only access is ordinary for L2TP, PPTP, SSTP and IKEv2 with EAP. WireGuard has no such option at all, because its peers are keys rather than users. For OpenVPN the answer comes from the server's client-certificate requirement: a gateway that demands both certificate and password will keep rejecting a password-only client, whatever is typed into the field.
Which component you need follows from the same answer. A password login under IKEv2 requires a client that speaks EAP, while a certificate login needs the client's private key and the server's chain. Install the wrong one and the failure reads like a credential error even though the authentication method itself is what is missing.
Change one thing, then retest
Establish three facts first: which protocol is running, how many secrets it defines, and which of them belongs to the machine rather than the user. Machines fail at the first stage and people fail at the second, and confusing the two is the whole of this problem.
Then change exactly one thing and retest from the same client. That discipline turns a confusing failure into a fix you can describe to the next person, which is more useful than a working connection nobody can explain.