Retiring PPTP/MS-CHAPv2: runbook for a legacy VPN

Twenty-character passwords, rotated monthly and kept in a vault, do not turn a PPTP server running MS-CHAPv2 into a modern VPN. The password is an input to an exchange whose weakness lives in the exchange. This runbook is for whoever inherited that server and has to move the users off it without cutting the site that depends on it. Work the steps in order, because each one leaves a record you will want when someone asks why access suddenly changed.

Write down the stack before touching anything

Three layers get collapsed into the word PPTP, and each fails in its own way. The tunnel is PPTP itself, GRE plus TCP 1723. The authentication is whichever PPP method the server offers, here MS-CHAPv2. The link protection is MPPE, whose keys are derived from that authentication exchange. Naming all three keeps a later fix from landing on the wrong layer.

Read the live configuration instead of trusting a wiki page, and note the file, the listener and the last sessions that authenticated.

grep -RniE 'mschap|mppe|require-mppe' /etc/ppp/options.pptpd /etc/pptpd.conf
ss -lntp 'sport = :1723'
journalctl -u pptpd -n 40 --no-pager

On a Windows remote access role the same inventory comes from two commands, and the second one matters because a role can advertise several methods at once while the clients in the field only ever negotiate the weakest one.

Get-VpnAuthProtocol
netstat -ano | findstr :1723

Decide what the tunnel actually carries today

List the consumers before choosing a replacement: roaming laptops, a branch router, a payment terminal, a set of field tablets. A consumer that only needs to reach one internal host is easy to move. A consumer embedded in hardware you cannot reflash may need an intermediate gateway instead of a client upgrade, and that decision belongs in the plan rather than in the middle of the cutover.

Then ask what an attacker who can observe or influence the login exchange would get. With MS-CHAPv2 the answer includes material that allows an offline recovery of the user's password, which is precisely why length and rotation do not repair the design: the recovered secret is valid on every system where the user reused it.

MPPE inherits the same weakness, since its keys come from that exchange, and it does not give you the per-packet integrity and replay behaviour of a modern AEAD cipher. A session that authenticates cleanly has proven compatibility with the configured checks and nothing more.

Neither a short lunch break nor a small user count converts a cryptographic property into a policy one.

Run the migration inside one maintenance window

Stand up the replacement, prove it with one pilot group, then stop the old listener rather than leaving it as a quiet fallback. A fallback that anyone can still reach is not a migration, and it keeps the weak exchange available for exactly the users who never bother to switch.

sudo systemctl disable --now pptpd
sudo ss -lntp | grep -E ':(1723|1194|51820)\b'
sudo nft list ruleset | grep -i gre

Close the firewall path in the same window. GRE has no port to remember, so a rule permitting protocol 47 by number is easy to overlook and leaves the service reachable even after the daemon is gone. Record the rule you removed, its previous position and the reason, so a later change review does not restore it by accident.

Handle credentials separately from configuration. Removing a client profile is not a revocation, and an account that still authenticates elsewhere has not been retired.

Verify the replacement does the jobs PPTP did

The checklist is not "does it connect". It is whether authentication, address assignment, DNS resolution, route selection, reconnect behaviour and peer verification all still hold under the replacement. Test each one on a pilot device, in that order, and write the observed result next to the expectation.

ip -4 addr show tun0
ip route get 198.51.100.23
resolvectl query intranet.example.net

An address on the interface proves the negotiation completed. It does not prove the far side authorized the route you expect, and the lookup above answers only for this host, not for a forwarded LAN. A resolver answer proves reachability of a resolver, not that split-DNS policy sends the right names to it.

Reconnect last, because that is where most replacements regress: suspend a laptop, change networks, and confirm the tunnel re-establishes without leaving stale routes behind.

Rollback, revocation and the record you leave behind

Rollback restores service; it does not restore security, and the difference needs saying out loud before the window opens. If the new path fails, bring users back through a second modern endpoint or a temporary gateway, not by re-enabling PPTP for everyone. Keeping one emergency path on the old protocol widens the exposure you just documented.

After cutover, revoke the accounts that authenticated over PPTP, expire their stored profiles, and confirm the GRE rule is gone from every edge device, including the DR copy nobody remembers.

Leave a short record: the protocols you found, the date each listener stopped, the replacement's supported client versions, and the owner who can re-open the decision. Password hygiene still matters afterwards, but as hygiene on a protocol that deserves it, not as an argument for keeping the old one alive.