Which VPN stage failed: IPsec, L2TP control, or PPP auth

You changed the password and nothing moved, because the failure was never in PPP. L2TP/IPsec reports one connection error for five quite different handoffs, and each handoff has its own repair. Work backwards instead: find the last stage that succeeded and change only what comes after it. The order below also decides which evidence you collect first.

Answer four questions in order

Force a fresh attempt, because some clients keep showing the previous error until the profile is disconnected and reconnected. Then answer this: was an IPsec security association present, did an L2TP control connection and a call appear, did PPP reach an authentication verdict, and did IPCP hand the client an address? The first no is the stage you fix. Everything after it is untested, so a rejected username proves nothing when no association ever existed.

Align the clocks on both ends before comparing. A retry that cleared IPsec and failed at PPP looks like a single failure when the client shows only the final message and the server log still holds the earlier attempt. Read by timestamp, not by whichever line is loudest.

When all you have is the user's screenshot, lean on the cheapest split: a wrong pre-shared key and an xl2tpd that never answers produce the same text in the Windows dialog, yet one needs a secret changed on both ends and the other needs a daemon started or a firewall rule on the server itself. A device in the middle cannot drop the inner 1701 once transport-mode IPsec has wrapped it, so do not go hunting for a path filter that is not there.

What each layer actually owns

IPsec protects packets between the two peers; L2TP carries a PPP session inside that protected path, which is why RFC 3193 specifies transport mode rather than a tunnel of its own. The client label says L2TP, so the tunnel and the login feel like one mechanism. They are not: the L2TP control connection authenticates the tunnel endpoints where a deployment enables it, and PPP separately authenticates the user with CHAP, PAP, or MS-CHAPv2 under server policy.

That split explains the two secrets people keep confusing. A pre-shared key authenticates the IPsec peers. A username and password identify the user to PPP. Retyping the Windows shared secret on a profile that authenticates with certificates changes nothing at the failing stage, and editing the PPP password cannot supply a missing protected channel. The same restraint applies to the identity check: do not switch off peer identity or certificate validation to get a tunnel, because what connects then is the path, not the peer.

Authentication is not the end of PPP either. After the user is accepted, IPCP negotiates the client address and the DNS and WINS options the server is willing to hand out. A client can pass CHAP or MS-CHAPv2 and still end up with no address, which is a failure inside PPP rather than a routing problem. Plain L2TP with no IPsec stays valid and unprotected, so a successful connect never proves the traffic is protected; check what the server enforces, not the client's label.

Decide from the first missing stage

Read the table by the first missing item, left to right. The right-hand column is the only work worth doing at that point; everything to its left is already proven, and re-testing it burns the outage window without adding information.

Three rows deserve a warning. The 1701 row is where Windows clients behind NAT tend to land: the association completes, then nothing arrives, and encapsulation is the cause rather than a bad password. The IPCP row is the one that gets misread as a route problem, because Windows wraps a missing address in error 720 and the tray icon only says the connection failed; that failure sits after authentication and before routing. The final row is not an IPsec failure at all even though the tray icon says disconnected.

Commands that separate the layers

On a Linux server running strongSwan, swanctl --list-sas lists established associations with their peer identity, and ipsec statusall covers older strongSwan and libreswan hosts. Underneath, ip xfrm state shows the kernel's actual associations, while ss -lunp | grep 1701 proves where xl2tpd is bound. Run xl2tpd -D in the foreground to watch control connections and calls appear, and turn on pppd debug in /etc/ppp/options.xl2tpd to see the method offered and the answer.

Once the logs show a successful authentication, the next question is whether IPCP completed. Check that the ip range in the [lns default] section of /etc/xl2tpd/xl2tpd.conf still has free addresses, and that /etc/ppp/options.xl2tpd actually carries ms-dns and ms-wins if the client expects them. An exhausted pool and a missing DNS option look different on the wire: the first leaves the client with no address and a 720, the second gives an address but no resolver, so names fail while pings to raw addresses work. Neither is repaired by re-entering the password.

On the client, the NetworkManager L2TP plugin writes the pppd conversation into the journal, so journalctl -u NetworkManager -b usually separates tunnel up, auth refused from no tunnel at all. On Windows, Get-VpnConnection reports the profile's real authentication settings, and the RasClient events under Application in Event Viewer name the failing component. When the dialog is too vague, enable netsh ras set tracing * enable.

Captures need one caution. With transport-mode IPsec the inner UDP 1701 is encrypted, so a capture on the outside interface shows ESP, or UDP 4500 under NAT-T, and no L2TP whatsoever. Missing 1701 in a capture is expected and not proof of a blocked port; watch whether the ESP or 4500 counters move.

NAT, MTU, and routes: where the stack misleads you

NAT breaks assumptions before anything is authenticated. ESP is its own IP protocol, so a translating device discards it unless the peers encapsulate; that is what UDP 4500 provides. On a Windows server that itself sits behind a home router or a cloud NAT gateway, the IPsec stage fails with error 789 until AssumeUDPEncapsulationContextOnSendRule is set to 2 under the PolicyAgent key and the machine restarts, and the failure stays indistinguishable from a closed port. Clients behind NAT are easier: with a public address on the server, NAT-T on UDP 4500 carries them and that value is not involved.

Once PPP is up, a black-holed MTU imitates a dead tunnel: small packets cross, a TLS handshake or a page load hangs, and the client may still display connected. Lower the interface MTU or clamp MSS at the gateway before blaming the server. Split-tunnel routing is the other impostor; a subnet pushed with the wrong mask leaves the tunnel healthy and one application unreachable. A private hostname adds a hop of its own: if the query leaves through the local resolver, the name fails to resolve before any route gets tested.

Checklist before you touch credentials

Work the list in order and stop at the first failing item. Every step is cheap, and each one rules out a whole class of edits.

1. Confirm the association exists on both ends, matched by peer identity rather than a connected label.
2. Confirm UDP 1701 reaches xl2tpd; an association with no call is your failure.
3. Read PPP's verdict, and if it authenticated, the IPCP result, before assuming the password is wrong.
4. Only now re-enter credentials in the format the server expects, since a domain prefix changes the account.
5. If it still fails, capture both ends with aligned timestamps and compare stage by stage.

Stopping at step two means a path or encapsulation problem, and no password edit will move it. Stopping at step three means the log already names the method or the address pool to fix. Either way the next change is one you can justify, and you stop cycling through settings that were never involved.