PPTP Says Your Password Is Wrong: Which Fix Comes First?

PPTP profiles that insist your password is wrong are telling you something narrower than it sounds. The secret is tested at the very end of a chain that starts with capability negotiation, so any mismatch earlier in that chain surfaces as an authentication failure. Resetting the password, retyping it, or recreating the profile therefore changes nothing. Read the negotiation first, then choose the fix by how much of the path you control.

Why the secret never gets tested

PPP authentication is negotiated: the server proposes methods, the client answers with what it can do, and both settle on one before any credential is exchanged. When the server offers only EAP-PEAP and the client's pppd does not implement it, the conversation ends at the proposal stage. The server records an authentication failure because that is the stage that failed, not because the password was compared and found wanting.

This is why the error is identical for a wrong password and for a method mismatch. Only the log distinguishes them, and only if the client is allowed to be verbose.

Read the negotiation, not the last error

Run the connection in the foreground with debugging on and read the authentication lines from the top. The log names the method proposed, the method accepted and where the exchange stopped. A profile that never leaves CHAP or MSCHAPv2 while the server expects PEAP is a method problem, not a credential problem. The last line of that log is where the client gave up, not where the cause sits.

sudo pppd call provider debug nodetach

Keep that output. It is also the evidence a network owner needs before changing server policy, and it settles the question of whether the password was ever in play.

The second cause hides in the secrets file

If the log shows the methods agreeing, look at the file that stores the secret. A newline or a trailing space written into the password field is sent as part of the password, so the server compares a different string than the one you typed. The file looks correct in an editor, which is exactly why this survives so many retries.

sudo cat -A /etc/ppp/chap-secrets

The dollar sign marks the end of each line in that output. A password field with anything before that mark, or a stray space between fields, needs rewriting with the quoting the tool documents.

Choose the fix by who owns the server

If the server is yours, allowing MSCHAPv2 for that account is the smallest change, and you should record that you accepted a weaker method on purpose. If it belongs to someone else, a client that implements EAP-PEAP is the honest fix; patching pppd makes the incompatibility your maintenance problem. If the protocol choice is still open, PPTP is the weakest part of the design and the migration is usually cheaper than keeping a patched client alive. Write that decision next to the profile so the next person does not reopen it.

Whichever route you take, test from a second machine on another network afterward. A saved profile can keep offering the old method and make a corrected server look broken. Then remove the debug setting, since verbose PPP logs can capture more than you want on a shared workstation.