Windows VPN Hardening: Fix Authentication Before the Tunnel

Your Windows VPN server asks for a username and a password, and that single dialog hides three unrelated duties. One proves who the person is, one keeps that proof from being replayed by someone watching the wire, and one decides which addresses they may touch afterwards. Most small deployments harden the tunnel first and leave the first two duties at their defaults, which is the wrong order.

Work in the order the attacker does. First comes what can be captured off the wire. Then what can be replayed later with that capture. Finally, what an authenticated attacker can reach once inside.

Three duties, one dialog box

Identity is the part people think about, and it is only a third of the problem. Proof of identity has to survive an observer who records the exchange and tries again later. Authorization is a separate decision that the server makes after identity is settled, and Windows keeps it in a different service from the one that validates credentials.

When all three live in one mental bucket, the usual outcome is a server that authenticates strongly and then permits the user to reach everything. Fixing that later is harder than deciding the policy now, because by then the firewall profile, the address pool and the routes all encode the old assumption.

Separate the three in your notes before touching a setting, then fix them from the weakest link upward.

Why MS-CHAPv2 cannot survive a replay test

If the server still accepts PPTP with MS-CHAPv2, the tunnel is not protecting the password in any meaningful sense. The challenge and response can be captured and attacked offline, and in 2012 a public cracking service demonstrated recovery from such a handshake in about a day for a typical password. A longer, more complex password raises the cost; it does not remove the material an attacker needs from the network.

The property you want is a credential that cannot be replayed. EAP-TLS with client certificates gives each device its own identity and lets you revoke exactly one device.

Certificate deployment is genuine work: a private CA, a revocation path that clients check, and a renewal plan that survives staff turnover. Treat that work as the project rather than as an obstacle between you and a working tunnel. Budget for it the way you would budget for a firewall replacement. A shared password is cheaper only until the first revocation.

A pre-shared key authenticates the pair, not the person

L2TP/IPsec with a pre-shared key proves that two gateways know the same secret. It says nothing about which human is connecting, and it cannot distinguish one employee from another at that layer. Use a long random value, well beyond the ten characters some guides suggest, because anyone who captures the handshake can attack the key offline.

Every client on that profile shares the secret, so removing one person means redistributing it to everyone else who remains. Keep a separate user authentication step on top of the machine-level secret, and move to certificates as the client population grows. A pre-shared key combined with MS-CHAPv2 is two weak layers, and the second one undoes the first.

Authorization belongs in Network Policy Server

NPS on Windows decides who may connect, and it does so after authentication has already succeeded. That separation is the most useful hardening control in the product, and many deployments leave it untouched.

Use policy conditions that reflect real constraints: group membership, the time window when support is staffed, and device state from a health check. Add a second factor where the data justifies the friction, and remember that the policy is evaluated per connection attempt, which makes it a live control rather than a document.

RADIUS accounting also gives you one record of who connected and when. That log is the difference between an incident review and a guess, and it exists whether or not anyone ever reads it.

Limit what a successful login can reach

The VPN adapter should land in a firewall profile that permits the services its role needs rather than the entire subnet. The routing question is separate from filtering. A full tunnel guards the client device and pushes every byte through your uplink, while a split tunnel keeps local traffic local and exposes the device to whatever network it happens to be on.

Neither choice is a security default. Both need to be written down next to the firewall profile they assume.

Verify the failure paths

Test what should break: a wrong password, an expired certificate, a revoked device, a user outside the group. Each should fail at a different point, and the log should say which one it was. Run the set against a test account first, then repeat it for a real user. A rejection that lands in the event log with no reason is worth fixing long before you need the record.

Then confirm which ports are published and why. PPTP needs TCP 1723 and GRE as an IP protocol rather than a port, IKEv2 needs UDP 500 and 4500, and L2TP needs UDP 1701 plus IPsec. Exposing a management interface so a client will connect is not a repair, it is a second incident waiting to be discovered.

Finally, decide what the server records and for how long. An endpoint with no authentication history cannot answer the first question after an incident, which is whether the attempt was ever authorized.