L2TP/IPsec fails: isolate IPsec, tunnel auth or PPP login

Three things authenticate inside one L2TP/IPsec connection, and only one of them involves the person dialling in. IPsec proves the tunnel endpoints, the L2TP control connection may prove the peers again with its own secret, and PPP then proves the user account inside the session. A failure at any stage looks like a generic login error in the client dialog and looks completely different in a server log. Work down the stages in order and stop at the first one that fails, because every stage below an untested one is untested too.

Three authentication stages, three different identities

IPsec proves who owns the endpoints, using a pre-shared key or a certificate. That identity belongs to machines or gateways, never to the human at the keyboard. When the peers cannot agree at this stage, no L2TP packet is exchanged at all.

The L2TP control connection can add a second, separate challenge-response exchange driven by a shared secret that both ends must hold.

RFC 2661 makes that control-connection authentication optional, which explains why the same mistake produces different symptoms on two servers. A deployment that never configured a tunnel secret skips the stage entirely; one that configured it on a single side fails before PPP is ever offered. PPP then authenticates the user with PAP, CHAP or MSCHAPv2 and hands the name to an account store that may be local, in chap-secrets, or on RADIUS. A wrong password at that point still leaves you with a working tunnel and a failed session.

Read the stopping point before you edit a config

Start with ipsec --version so you know whether the status output belongs to strongSwan or Libreswan. Then read the server log, not the client dialog, because the server records which stage refused.

One line usually settles the ticket: an IKE or proposal complaint is stage one, a control-connection message is stage two, and a PPP method or account rejection is stage three. Copy that line into the ticket with the timestamp. Guessing from the client side wastes the one piece of evidence you already have.

Keep key material and passwords out of that paste; the stage name routes the work, and a leaked pre-shared key reopens the ticket with worse consequences.

Step one: does IPsec have an association?

Run ipsec statusall on strongSwan or ipsec whack --status on Libreswan and look for an established child association with non-zero counters. ip xfrm state shows the kernel view on both. An installed pair of SAs with counters climbing means stage one is done and you can move on.

No association at all points at the peer address, the proposal set, or the pre-shared key, and occasionally at a device that rewrites UDP 500 while dropping UDP 4500. An association that establishes and then disappears after a few seconds is usually a lifetime mismatch between the two ends rather than a credential problem. Check whether both sides list the same encryption and hash proposals before you retype anything. If they do not, no key will ever work.

Stop while the association is missing. Editing PPP options at that point changes nothing and hides the real fault from the next person.

Step two: did the L2TP control connection authenticate?

Once IPsec is up, watch the L2TP daemon for a control connection that reaches an established state, since PPP cannot begin before that. A refusal on the control connection means the tunnel secret differs between the ends, or one end demands a secret the other never sends. Clients often expose a single field labelled shared secret, and it normally belongs to IPsec rather than to L2TP. Filling it in does not configure the tunnel secret, and clearing it does not disable it.

If neither side has a tunnel secret configured, skip this stage and treat a control-connection failure as reachability instead. Confirm that UDP 1701 reaches the daemon and that both ends agree on the same encapsulation. A firewall rule written for one of those two conditions is a common cause of a connection that half opens.

Only a session that starts negotiating PPP has actually cleared the tunnel stage.

Step three: is PPP rejecting the account?

A PPP failure looks different from the outside: the tunnel is established, the session starts, and the daemon logs an authentication method failure or an account rejection. Read the method named in that message. PAP and CHAP fail for different reasons, and a server that refuses one will reject a client offering only that one.

On a Linux server, inspect the options file the daemon passes to PPP, typically /etc/ppp/options.xl2tpd, and confirm which methods are accepted and where accounts are resolved. A name that exists in RADIUS but not in the local secrets file fails cleanly and looks like a bad password. Then check that the client offers a method the server accepts, rather than a stronger one the server refuses to negotiate. Changing the pre-shared key to repair this stage wastes an afternoon and changes nothing.

When the session finally comes up, address assignment, DNS and routes are still unchecked, and each fails quietly in its own way. Keep the three layers separate in your notes: a correct key with a wrong account always fails, and repairing one layer never repairs another.