Shared Secret or User Login: Which L2TP/IPsec Field Failed?
A pre-shared key proves the peer, while the PPP username and password prove the person. The error code tells you which of the two layers broke.
One office can pass the same IPsec secret to every laptop while each person still signs in with an individual account, which is why "the key is right" and "the password is right" can both be true and the login still fails. L2TP and IPsec authenticate different parties at different stages. A comparison of the two layers, and the error code that separates them, ends most of these tickets faster than swapping both values again. The stages are not interchangeable, and the message in front of you already says which one is in play.
Two layers, two different identities
IPsec peer authentication runs first. The client and the gateway prove who they are to each other, using a pre-shared key or a certificate, before any tunnel payload is protected. The PPP exchange inside the L2TP session runs afterwards, and that is where your user name and password are checked against the server's account store.
The stages are independent, so a valid user account cannot rescue a wrong IPsec key, and a correct key cannot rescue an expired password. Write the two apart in the ticket and the diagnosis usually falls out of the first log line that names a stage.
| Observed failure | Stage that rejected it | Field to touch |
|---|---|---|
| Security layer error 789 during initial negotiation | IKE and IPsec peer authentication | The pre-shared key or the certificate |
| Error 691, credentials not recognised | PPP user authentication | User name, password, or account policy |
| Tunnel forms, then drops on the first packet | Neither, usually routing or MTU | Address pool and interface configuration |
| Prompt repeats with no error text | Often the client type selection | The connection profile, not the secret |
The shared secret proves the peer
A pre-shared key is a group credential held by the gateway and by every client that connects to it. It establishes that the peer knows the key, and from it IKE derives the keys that protect the connection. Nothing about that exchange identifies the human at the keyboard. That is the whole reason a second, user-level login exists in the same tunnel.
That design has a practical consequence for revocation. Losing one laptop means rotating the secret for every device that uses it, unless the deployment moves to certificates, where a single device can be removed without touching the rest. The trade is administrative effort against blast radius.
A key that is typed into a profile is also the easiest credential to leak through screenshots and chat. Treat it as shared infrastructure material rather than as a personal password, because that is exactly what it is.
The login belongs to PPP
Inside the L2TP session, PPP negotiates authentication and asks the server to verify the pair of values you typed. On Windows that is the same user name and password the profile prompts for, and on a router it is whatever the PPP profile references. It is checked against the account store, not against the key. Two people can share a laptop and a key and still be told apart at this stage.
Because it is user authentication, all the usual account policies apply: expired password, locked account, dial-in permission, or a name that must carry a domain. Error 691 reports that combination as rejected, so read the server's accounting record before you retype anything.
Let the error pick the field
Error 789 names the security layer and points at the IPsec stage. Confirm that the pre-shared key on both sides matches exactly, that the peer identity expected by the gateway matches what the client sends, and that the client is configured for L2TP/IPsec rather than another type.
Error 691 names credentials and points at PPP. Check the account state and the exact name format before changing the secret, because changing both at once destroys the evidence you were reading.
When the tunnel comes up and traffic still stops, stop editing authentication fields altogether. Look at the address pool, the route back to the client subnet, and the MTU: a comparison of the two layers only helps while the failure is still inside them.