Running your own VPN server on Windows Server gives you encrypted remote access to your network without paying a third-party subscription or trusting a provider with your traffic logs. Windows includes everything you need: the Routing and Remote Access Service (RRAS) role supports SSTP and L2TP/IPsec out of the box, and IKEv2 works with a certificate. This guide compares the protocol options, walks through the RRAS setup, and lists the firewall rules that actually need to exist. If you need a box to run this on, Windows VPS plans with a public IP and 2 GB of RAM are plenty for a small VPN.
Choose your VPN protocol first
The protocol decision drives every later step, so make it consciously. Here is how the realistic options on Windows Server compare:
| Protocol | Ports | NAT friendly | Client support | Notes |
|---|---|---|---|---|
| SSTP | TCP 443 | Excellent — rides HTTPS | Windows, macOS, Linux (via clients) | Needs an SSL certificate; survives strict firewalls |
| L2TP/IPsec | UDP 500, 4500, 1701 | Good with NAT-T | All major OSes, phones | Pre-shared key or certificate; older but solid |
| IKEv2 | UDP 500, 4500 | Good | Windows, iOS, Android, macOS | Fast reconnects on roaming; needs certificate |
| WireGuard | UDP 51820 (default) | Good | All major OSes | Fastest and simplest, but the server side is best on Linux; on Windows it is experimental |
For a Windows-only shop, SSTP is the low-friction winner: it uses the same port as HTTPS, so it works from hotel and office networks that block everything else. If you need to support iPhones and Android devices as well, add IKEv2 — modern mobile OSes have native clients and roam between Wi-Fi and cellular without dropping the tunnel.
Install the Remote Access role
From an elevated PowerShell prompt, install the role and its management tools:
Install-WindowsFeature RemoteAccess -IncludeManagementTools
Install-WindowsFeature RSAT-RemoteAccess-MgmtThen open Server Manager → Tools → Routing and Remote Access, right-click the server, and choose Configure and Enable Routing and Remote Access. Select Remote access (dial-up or VPN), then VPN. When asked how to assign addresses, use a static pool such as 10.10.10.100–10.10.10.200 — it is simpler to reason about than DHCP on a small VPS and avoids conflicts with your LAN subnet.
Set up SSTP (port 443)
SSTP requires an SSL certificate bound to the VPN server’s hostname. A publicly trusted certificate from Let’s Encrypt or a commercial CA avoids client warnings. If you are testing, a self-signed certificate works, but every client must then trust it manually.
In the Routing and Remote Access console: right-click the server → Properties → Security tab → select the certificate under SSL Certificate Binding. On the IPv4 tab, confirm the static pool from the previous step, then under IPv4 → General enable Remote access (dial-up or VPN) and LAN routing. Apply the changes and start the service.
Open the inbound port on Windows Firewall:
New-NetFirewallRule -DisplayName "SSTP VPN 443" -Direction Inbound -Protocol TCP -LocalPort 443 -Action AllowSet up L2TP/IPsec as a fallback
L2TP/IPsec is useful when clients cannot do SSTP (some older embedded devices). In the RRAS console: server Properties → Security tab → under L2TP, check Allow custom IPsec policy for L2TP connection and enter a pre-shared key of at least 20 random characters. Then open the three required ports:
New-NetFirewallRule -DisplayName "IKE 500" -Direction Inbound -Protocol UDP -LocalPort 500 -Action Allow
New-NetFirewallRule -DisplayName "NAT-T 4500" -Direction Inbound -Protocol UDP -LocalPort 4500 -Action Allow
New-NetFirewallRule -DisplayName "L2TP 1701" -Direction Inbound -Protocol UDP -LocalPort 1701 -Action AllowPre-shared keys are a weaker authentication factor than certificates, which is why SSTP or IKEv2 with a real certificate is the better long-term configuration. Rotate the key whenever an administrator leaves the team.
Control who can connect
By default, any user in the Dial-in permitted group can connect. The clean pattern is to create a dedicated security group and grant it dial-in permission via the netsh ras remote access policy, or simply set Allow access on the specific user accounts that need the VPN. Restrict membership to a handful of named users, and enable the Store passwords using reversible encryption option only if a legacy client requires it — it weakens password storage, so avoid it when possible.
Test the tunnel and verify the server side
From a client, create a VPN connection pointing at the server’s public IP or hostname, using the protocol you configured. Before you even connect, verify the ports are reachable from outside:
Test-NetConnection -ComputerName vpn.example.com -Port 443Once connected, confirm you are actually routing through the tunnel: check the client’s public IP (it should now be the server’s IP) and verify you can reach a resource on the server’s LAN. On the server, watch live sessions with:
Get-RemoteAccessConnectionStatistics | Format-TableIf the connection drops immediately, the three most common causes are: the certificate hostname does not match what clients type, the static pool overlaps a real subnet, or a provider-level firewall is blocking the UDP ports before Windows Firewall ever sees the traffic.
Ongoing maintenance
Treat the VPN server like any other exposed service: patch it on the same schedule as your other servers, watch the security event log (Event ID 20226 in the RemoteAccess log shows failed authentication attempts), and revoke dial-in permission immediately when someone leaves. On a small team this is a thirty-minute setup that replaces a paid VPN subscription. If you are provisioning a server for this today, our Windows VPS options include the public IP and firewall controls you need.
