Why do PPTP and L2TP/IPsec stop before the username prompt?
No username prompt means PPP never started, so the fault sits in transport, key exchange or tunnel setup. Check the stage order before reinstalling.
No username prompt is a diagnostic gift: PPP has not started, so the account, the password and the domain policy have not been consulted yet. In a PPTP or L2TP/IPsec connection the client asks for credentials only after the tunnel exists and the server has begun a PPP session. Everything that can fail before that moment is transport, key exchange or tunnel setup, which is a far smaller surface than "the VPN is broken".
A missing prompt narrows the fault to three stages
Write down the last stage that visibly succeeded, because each one has a different owner and a different fix. Guessing at the account settings while you are stuck two stages earlier is how an afternoon disappears.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
A client that times out with no prompt never got an IPsec association, so the fault is in IKE or in whether your packets reach the gateway at all. One that reports verifying credentials and then drops got further than the message suggests. A prompt followed by a rejection is PPP authentication, and that belongs in an account article rather than this one.
Stage one: the protocol a firewall quietly drops
PPTP needs TCP 1723 for its control channel and IP protocol 47 for the data path, and the two travel separately. Plenty of networks forward 1723 and drop protocol 47, which produces a tunnel that negotiates and then carries nothing at all. A router doing NAT also needs a GRE-capable pass-through, and an IPv6-only access path cannot carry PPTP under any configuration.
L2TP over IPsec spends port 500 on IKE and port 4500 on NAT traversal, then wraps the L2TP traffic itself in 1701, with ESP carrying the protected payload once the association exists. Allow the two control ports but not ESP and you get exactly the symptom in the title: visible progress, then a dead client before any credential dialog. Testing from a phone hotspot is a cheap way to separate a client problem from a path problem.
Stage two: a key that is not the key, a proposal that is not offered
A mismatched preshared key fails quickly and quietly, and the usual version is a key that looks correct on screen while carrying a pasted line break or a trailing space. On a Linux client the dialog is not necessarily the source of truth: the NetworkManager L2TP plugin keeps secrets in files under /etc/ipsec.d/, and an older per-connection file that /etc/ipsec.secrets still includes will be used instead of the one you just typed. Copy that file somewhere safe, take it out of the include path, then retype the key by hand.
The other half of this stage is the proposal. Both ends have to settle on the same phase 1 algorithm set — encryption, integrity and Diffie-Hellman group — and on matching ESP transforms for phase 2, or the association never forms at all. A gateway that offers only 3DES, SHA1 and MODP1024 will refuse a client configured for stronger algorithms, and its log names the refused transform. The log names the mismatch if you read it instead of restarting the service again. Instead of copying an algorithm string out of a forum thread, ask the gateway which transforms it will really negotiate: ike-scan pointed at its address returns the transforms it will negotiate. If the only offer is cryptography your policy no longer permits, the fix belongs at the gateway, not in a client downgrade.
On Windows the key and the authentication method live in the VPN profile, and a mismatch surfaces before the credential prompt rather than after it. Where the receiver is a Windows Server, confirm that the remote access role is installed, that the certificate matches the name clients connect to, and that no port filter is narrower than the protocols above.
Stage three: the tunnel exists and PPP never starts
When IKE completes and the prompt still never appears, look at the tunnel daemon rather than the firewall. L2TP needs something listening on UDP 1701 — xl2tpd or kl2tpd on Linux, the remote access service on Windows — and a service that is installed but stopped looks identical from the client side to a dropped packet. Check the listener before you re-open rules you already verified. PPP then has to negotiate, and the first LCP exchange is where a silent failure usually lands.
One trap in this stage is not a network fault at all: Windows permits a single connection of a given VPN type at a time, so a second attempt returns error 937, "another connection of this type is in use". That is a local rule, and the way around it is a different device, a different tunnel type, or sharing the one connection that already exists.
Read the log in stage order instead of guessing
Stop the client, start it again, and read the components in the order they log. That means the IPsec daemon first — strongSwan or Libreswan, and ipsec --version tells you which — then the L2TP daemon, then pppd. Whichever component wrote last before the failure marks the stage to investigate, because anything that comes after it in the sequence never ran at all.
Verify with a fresh connection rather than a saved session, because a client reconnecting from cache can skip parts of the exchange and reproduce a stale result. Confirm reach, key exchange, tunnel and PPP one at a time, in that order. The missing prompt then stops being a mystery and becomes the second line of a list you can actually work through. That list is also what you hand to the network team, who will otherwise be asked to check the firewall for a fault that lives in an unstarted daemon.