Setting Up a Windows VPN Server (and When Not To)

Remote users need a way into the office network, and the box in the closet already runs Windows Server. The question is which of its three VPN options to use, how to set one up without leaving a hole in the edge, and when a different product is the better answer. This guide covers every Windows VPN server option, the RRAS build step by step, the security review that has to go with it, and the cases where you should not run one at all.

TL;DR

• Short answer. Windows Server becomes a VPN server through the Routing and Remote Access role, running SSTP or IKEv2; the Windows 10 and 11 "incoming connection" feature is PPTP only and belongs nowhere near a business.
• What changed. Microsoft deprecated PPTP and L2TP in RRAS in October 2024, and Windows Server 2025 ships with both switched off for new installs.
• The build. One certificate that matches the public name, the Remote Access role, a static address pool, NPS for who gets in, and one port at the edge.
• When not to. A firewall that already has a VPN, or a Zero Trust product such as Entra Private Access, beats a Windows VPN server for offices without a server team.

Three Ways Windows Can Be a VPN Server

Windows carries three different things that answer to "VPN server", and they share almost nothing except the name.

The first is the incoming connection feature in Windows 10 and 11. Open Network Connections, choose New Incoming Connection, pick a user, and the desktop starts listening for remote clients. It runs PPTP, a protocol from 1999 whose authentication has been broken for over a decade, and it needs TCP 1723 plus GRE forwarded from the router. There is no certificate, no policy engine and no log worth reading. Treat it as a lab curiosity and refuse it in any business.

The second is Routing and Remote Access Service on Windows Server, usually shortened to RRAS. It is the role that turns a server into a VPN gateway for four protocols: PPTP, L2TP over IPsec, SSTP and IKEv2. It hands clients an address from a pool, routes them into the LAN, and either checks credentials itself or hands the decision to Network Policy Server. RRAS is what people mean by a Windows VPN server, and it is the build in this guide.

The third is Always On VPN. It is not a separate server; it is the Windows client side of RRAS or any IKEv2 gateway, configured by profile so the tunnel connects on its own. Microsoft positions it as the replacement for DirectAccess, and it adds a device tunnel that connects before anyone signs in, which is what makes Group Policy and patching work for a laptop that never visits the office. It needs certificates, NPS and a profile deployed through Intune or PowerShell, so it is the most work of the three and the only one that behaves like a managed product.

The remote support tools in our remote access software roundup sit next to this table rather than in it: they put a technician on a screen, while a VPN puts a device on the network.

The Protocols, and What Microsoft Switched Off

RRAS has carried the same four protocols since Windows Server 2008, and in October 2024 Microsoft formally deprecated two of them. Richard Hicks, who has written extensively on Always On VPN, summarised the announcement on October 11, 2024: PPTP and L2TP are deprecated in RRAS, both ship in Windows Server 2025, and Microsoft may remove them from a future release. PPTP went because its MS-CHAPv2 authentication can be cracked offline. L2TP over IPsec is still sound, but IKEv2 does the same job with less overhead and better reconnects, so there is no reason to start a new L2TP deployment.

Windows Server 2025 made the deprecation concrete. Per Microsoft's RAS installation guide, "Beginning with Windows Server 2025, new RRAS setups don't accept VPN connections based on PPTP and L2TP protocols", while SSTP and IKEv2 "are still accepted without any change". The same page carries two details that matter for migrations: an in-place upgrade from Server 2019 keeps PPTP and L2TP enabled, and the change "doesn't affect Windows clients operating systems". A server that was upgraded rather than rebuilt still answers on TCP 1723 until somebody turns it off.

That leaves two protocols worth deploying, and they differ in one way that decides the choice.

SSTP wraps the tunnel in TLS on TCP 443. It passes through hotel Wi-Fi, guest networks and most corporate proxies because it looks like HTTPS, and the server needs exactly one inbound port. It is Windows-only on the client side, which is fine for a Windows fleet and useless for a MacBook.

IKEv2 runs IPsec on UDP 500 and 4500. It reconnects cleanly when a laptop moves from Wi-Fi to a phone hotspot, it is the only protocol a device tunnel can use, and every major operating system has a native client for it. Its weakness is the port pair: some guest networks block UDP 500 and 4500 outright, which is why Microsoft's Always On VPN profile supports falling back from IKEv2 to SSTP.

The sensible default for a small office is both: IKEv2 first, SSTP as the fallback, and the PPTP and L2TP ports disabled in the RRAS console whether or not the server version already did it for you.

Building an RRAS Server Step by Step

The build below assumes one Windows Server 2022 or 2025 machine, domain joined, with a static private address, sitting behind a firewall that forwards the VPN ports to it. Microsoft's own tutorials put the VPN server on two network adapters, one internal and one in a perimeter network. A small office rarely has a perimeter network, and a single adapter behind the firewall with only the VPN ports forwarded is a defensible shape as long as the firewall does the filtering.

1. Get the certificate first

The certificate is the step people skip, and it is the one that breaks the build. SSTP needs a server certificate whose subject or subject alternative name matches the public DNS name clients type in, for example vpn.contoso.com, with the Server Authentication purpose. IKEv2 wants the same certificate plus the IP security IKE intermediate purpose, which Microsoft's certificate tutorial adds by duplicating the RAS and IAS Server template and supplying the public name in the request.

Buy it from a public CA or issue it from your own Active Directory Certificate Services, but know what each costs you. A public certificate works on every client with no extra steps. An internal certificate means every client has to trust your root, and the certificate revocation list has to be reachable from the internet, or SSTP clients fail with a revocation error before they ever reach the server. The video below walks the public-certificate route on Server 2022, including binding it to SSTP, which is the part the RRAS wizard never mentions.

2. Install the role

Two lines in an elevated PowerShell:

powershell
Install-WindowsFeature DirectAccess-VPN -IncludeManagementTools
Install-WindowsFeature NPAS -IncludeManagementTools

The first line is the Remote Access role with the DirectAccess and VPN (RAS) service; the second is Network Policy Server, which you want on this server or a neighbour. Server Manager's Add Roles wizard does the same with more clicks.

3. Configure RRAS for VPN only

Open the Routing and Remote Access console, right-click the server, choose Configure and Enable Routing and Remote Access, pick Custom Configuration, and tick VPN access only. Microsoft's guide then has you set a static address pool on the IPv4 tab, which is the right call in a small office: a range of twenty or thirty addresses from the LAN subnet that DHCP does not hand out, so VPN clients land on the same network as the printers and the file server without a routing exercise.

Then open Ports under the server node. Each protocol is a WAN Miniport device with its own properties. Clear both inbound boxes on WAN Miniport (PPTP) and WAN Miniport (L2TP). Leave SSTP and IKEv2 enabled and set their Maximum ports to the number of simultaneous users you expect; the default of 128 per protocol is fine for an office of thirty.

4. Hand authentication to NPS

RRAS can check passwords against Active Directory by itself, and that is where most small deployments stop. It is also where the holes start, because "any domain user with dial-in allowed" is not a policy. Open the server's Properties, switch the Security tab to RADIUS Authentication, add the NPS server with a shared secret, and on the same tab bind the SSTP certificate. In NPS, add the RRAS server as a RADIUS client, then create a network policy that grants access to one security group, VPN Users, with EAP as the authentication method. The group is how a leaver loses VPN access on the day they leave, which our guide to domain controller roles covers from the Active Directory side.

5. Open the firewall

One rule for SSTP: TCP 443 inbound from the internet to the VPN server's private address. Two for IKEv2: UDP 500 and UDP 4500 to the same address, which Microsoft's guide states as the baseline requirement. Nothing else. The temptation is to forward "a few extra ports while you are in there"; the mechanics and the risk are in our explainer on port forwarding. If the server has a second adapter facing the internet directly, turn on the Windows Firewall on that adapter and let RRAS add only its own rules.

6. Build the client connection

On a Windows client, one PowerShell line creates the connection, and the same line goes into a script for the fleet:

powershell
Add-VpnConnection -Name "Office VPN" -ServerAddress vpn.contoso.com `
  -TunnelType Ikev2 -AuthenticationMethod Eap -EncryptionLevel Required `
  -SplitTunneling $false -RememberCredential $false

Swap IKEv2 for Sstp on a client that sits behind a network that blocks UDP 500. The two switches at the end are deliberate and the next section explains them.

The Security Review Nobody Schedules

A VPN server is a door on the internet with your domain behind it. The build above opens it; this list keeps it from being the easiest way in.

1. MFA, through NPS. The NPS extension for Microsoft Entra multifactor authentication adds a second factor to every VPN sign-in, and Microsoft's Always On VPN overview lists RADIUS with the NPS extension as the supported path. Put NPS on its own server if you can. In the r/sysadmin thread below, an admin added the extension to a server that was also running RRAS and hit a policy error on every connection; the reply that fixed it was to stand up a separate NPS box and point RRAS at it.
2. A group, not "dial-in allowed". The NPS policy grants VPN Users and nothing else. Remove the account from the group and the VPN is gone, whatever the account's dial-in tab says.
3. PPTP and L2TP off, checked twice. Once in the RRAS ports dialog, once with a port scan from outside. An upgraded server keeps answering on TCP 1723.
4. Decide on split tunnelling on purpose. With split tunnelling off, every packet from the client crosses the VPN, which costs bandwidth on the server's line and puts the client's web browsing behind your firewall. With it on, the client's home network and the office network are joined through one machine. Neither is wrong; "whatever the wizard chose" is.
5. No RDP from the internet, ever. The VPN is the way in, and Remote Desktop stays on the inside with Network Level Authentication turned on. A forwarded 3389 next to the VPN port undoes the whole exercise.
6. Patch the edge like it is exposed, because it is. RRAS and the firewall in front of it get updates in days, not quarters, and the VPN server does not double as a file server or a domain controller.
7. Read the logs. RRAS writes connection logs under C:\Windows\System32\LogFiles and NPS writes to the Security log; a sign-in from a country nobody works in is the alert that matters.

Across a fleet, the check that matters is which laptops still carry an old profile. On OpenFrame that is one script across a client's devices running Get-VpnConnection, with the output collected so the PPTP profiles show up as a list rather than a surprise.

Always On VPN: When the Server Is Worth Keeping

If the laptops are domain joined or Entra joined and managed, the RRAS server you just built can do one more thing: connect on its own. Always On VPN is a profile, pushed by Intune or a PowerShell script, that tells the Windows client when to bring the tunnel up and how to authenticate without a password prompt.

The feature with no equivalent anywhere else is the device tunnel. Microsoft's overview describes it as a tunnel that "allows the VPN to establish connectivity before user sign-in", which means Group Policy applies, the password reset the user needs at the lock screen reaches the domain controller, and the management tools can reach the laptop before anyone touches it. The same page sets its limits: IKEv2 only, no SSTP fallback, and "Device Tunnel can only be configured on domain-joined devices running Windows 10 Enterprise or Education version 1709 or later". A fleet of Windows 11 Pro machines gets the user tunnel, which connects after sign-in and supports both protocols.

Authentication moves from passwords to certificates. The user tunnel can use Windows Hello for Business or a user certificate issued by your CA, and the device tunnel needs a machine certificate from the same CA. That is the real cost of Always On VPN: a working PKI with autoenrollment, which the certificate tutorial linked above builds in an afternoon and an office without a server team may never want to own.

The thread below is the question every hybrid shop asks. The poster had a mix of domain-joined and Entra-joined machines and wanted one Always On VPN setup for both. The replies split the way the market has: one camp pointed to Richard Hicks's guides for deploying it on-prem or in Azure, the other said they were evaluating Zero Trust products instead and warned that their DirectAccess clusters spent too long on "Connecting". Both are right, and the deciding factor is whether the office has somebody who wants to run a PKI.

For an Entra-joined fleet, the walkthrough below covers the certificate and profile pieces end to end, including the parts that differ from the domain-joined tutorials.

When Not to Run a Windows VPN Server

The build works. The question is whether anyone should be running it, and for a growing share of small offices the answer is no.

The firewall at the edge almost certainly has a VPN of its own. A business firewall from any of the usual vendors terminates IKEv2 or an SSL VPN on the same box that already does the filtering, with its own client for Windows and macOS, MFA through the same RADIUS server, and no Windows Server to patch. If the office has that firewall and a Mac on staff, the firewall wins by default, and the one caveat is that firewall VPN code has carried its share of critical bugs, so the patching rule above applies there too.

Zero Trust Network Access products take the other route: no inbound port at all. A connector inside the network dials out to a cloud service, the client on each laptop dials the same service, and the service brokers access to named applications rather than to the whole subnet. Microsoft's version is Entra Private Access. Per its overview, remote users "don't need to use a VPN to access these resources if they have the Global Secure Access Client installed", with Quick Access covering a list of internal names and addresses and per-app access scoping down from there. It is licensed as a standalone product or inside the Microsoft Entra Suite, on top of Entra ID P1 or P2.

The part that changes the security model is who decides. Conditional Access evaluates every connection against the user, the device and its compliance state, which is the same policy engine our IAM solutions guide covers, and the same one the Microsoft 365 sign-in already uses.

Three questions settle it. Does anyone on staff want to own a Windows server and a certificate authority? If not, stop here and use the firewall or a ZTNA product. Does the fleet include Macs, phones or contractors' machines? If yes, RRAS with SSTP is out and IKEv2 on the firewall or a ZTNA client is in. Does the office need a laptop to reach the domain before sign-in? If yes, Always On VPN's device tunnel is the one feature the alternatives do not match, and the RRAS server earns its keep. Where the office network itself is still being planned, the small office network design checklist settles the edge first.

Every office that has inherited a VPN server has also inherited its firewall rules, and the rule list tells the story the handover notes left out.

The Short Version

Windows Server runs a sound VPN through RRAS with IKEv2 and SSTP, as long as the certificate matches the public name, NPS decides who gets in, MFA sits in front of it, and PPTP and L2TP are off. Always On VPN turns that server into something a managed fleet can use without a password prompt, at the price of a PKI. For an office with no server team, a Mac in the mix, or no appetite for an inbound port, the firewall's VPN or a Zero Trust product does the same job with less to patch.

Next reads: Network Level Authentication for the RDP sessions that happen inside the tunnel, and what WinRM is for managing the servers you reach through it.