How to Configure Remote Access VPN with SSTP on Windows Server 2022

What Is SSTP and Why Use It

Secure Socket Tunneling Protocol (SSTP) is a VPN tunneling protocol developed by Microsoft that encapsulates Point-to-Point Protocol (PPP) traffic inside HTTPS (SSL/TLS) on port 443. Because it uses the same port as standard HTTPS web traffic, SSTP VPN connections can traverse virtually any corporate firewall, web proxy, and NAT device without requiring special firewall rules beyond outbound HTTPS. This makes SSTP the most firewall-friendly VPN protocol available on Windows Server.

SSTP was introduced in Windows Server 2008 and Windows Vista SP1. It is natively supported by all Windows VPN clients from Vista onwards, making deployment straightforward in Windows-centric environments without installing third-party VPN clients. SSTP uses SSL/TLS for encryption and authentication, with the server presenting an SSL certificate that the client validates. The client authenticates via PPP authentication methods including MS-CHAPv2 and EAP-TLS.

Compared to IKEv2, SSTP has slightly higher overhead due to the HTTPS encapsulation, and it does not support Machine Tunnel (pre-logon). However, its near-universal compatibility with strict firewalls makes it valuable as a fallback protocol, and many organizations configure VPN clients to try IKEv2 first and fall back to SSTP. In Windows Always On VPN profiles, both protocols can be configured with automatic fallback.

Installing the RRAS Role for SSTP VPN

SSTP VPN is implemented through the Routing and Remote Access Service (RRAS) role in Windows Server 2022. Install the required features:

Install-WindowsFeature -Name DirectAccess-VPN, Routing -IncludeManagementTools
Install-WindowsFeature -Name RSAT-RemoteAccess-PowerShell

The DirectAccess-VPN feature name is somewhat misleading — it installs the full RRAS VPN capability, not just DirectAccess. The Routing feature is needed if this server will also perform NAT or IP routing. Reboot may be required after installation.

Verify the installation:

Get-WindowsFeature DirectAccess-VPN, Routing | Select-Object Name, InstallState

The RRAS server should have two network interfaces: one connected to the internet (or DMZ) and one connected to the internal network. Assign static IP addresses to both. The internet-facing NIC’s IP (or the public NAT address) must have a valid SSL certificate bound to the FQDN that VPN clients will use to connect (e.g., vpn.contoso.com).

Configuring RRAS as a VPN Server

After installing the role, open the Routing and Remote Access MMC console by running:

rrasmgmt.msc

Right-click the server name and select “Configure and Enable Routing and Remote Access”. In the wizard, select “Custom Configuration”, then check “VPN access”. After the wizard completes, start the RRAS service when prompted.

Alternatively, configure via PowerShell. Install RRAS as a VPN server only:

Install-RemoteAccess -VpnType Vpn

Configure the IP address assignment for VPN clients. Using a static pool:

Add-VpnServerIPv4AddressRange -StartIPAddress 192.168.200.1 -EndIPAddress 192.168.200.100

Configure which authentication protocols RRAS accepts. For SSTP with MS-CHAPv2:

Set-VpnAuthProtocol -UserAuthProtocolAccepted MSChapv2, EAP
Set-VpnServerIPv4AddressAssignment -IPAddressAssignmentMethod StaticPool

Set RRAS to use RADIUS (NPS) for authentication — this is required for domain user authentication and connection policy enforcement:

Set-RemoteAccessRadius -ServerName "NPS01.contoso.com" `
  -SharedSecret "StrongRadiusSecret!2024" `
  -Score 10 `
  -AccountingOnOffMsg Enabled `
  -AddressResolutionProtocol IpTcp

SSTP Certificate Requirements

The SSTP certificate requirement is the most critical configuration step. SSTP requires an SSL/TLS certificate bound to the RRAS server that meets these criteria:

1. The certificate’s Subject or Subject Alternative Name must match the FQDN that VPN clients use to connect (e.g., vpn.contoso.com). This FQDN must resolve publicly to the RRAS server’s IP address (or the NAT IP if RRAS is behind a firewall).

2. The certificate must be trusted by VPN clients. A certificate from a public CA (DigiCert, Let’s Encrypt, etc.) is trusted automatically. An internal CA certificate requires deploying the CA root to all VPN clients via Group Policy or manual installation.

3. The certificate must be in the Local Machine > Personal (My) certificate store on the RRAS server.

4. The RRAS service account must have read access to the certificate’s private key.

Install a certificate from a public CA (PFX format) on the RRAS server:

$PfxPassword = ConvertTo-SecureString -String "PfxPassword!" -AsPlainText -Force
Import-PfxCertificate -FilePath "C:Certsvpn-contoso-com.pfx" `
  -CertStoreLocation "Cert:LocalMachineMy" `
  -Password $PfxPassword

After importing, get the certificate thumbprint and bind it to SSTP:

$thumb = (Get-ChildItem Cert:LocalMachineMy | Where-Object Subject -like "*vpn.contoso.com*").Thumbprint
Set-RemoteAccess -SslCertificate (Get-ChildItem Cert:LocalMachineMy | Where-Object Thumbprint -eq $thumb)

You can also bind the certificate to SSTP via the registry (RRAS reads this at service start):

# RRAS uses the certificate bound to HTTPS on port 443 via HTTP.sys
netsh http add sslcert ipport=0.0.0.0:443 certhash=THUMBPRINTHERE appid="{BA23CD2C-48AB-46C9-94B8-8A07D75F0BB3}"

Restart the RRAS service after certificate changes:

Restart-Service RemoteAccess

Firewall Rules and Port 443 Considerations

SSTP uses TCP port 443 — the same port as HTTPS. If the RRAS server is also running IIS hosting websites on port 443, there will be a conflict because both IIS and RRAS attempt to bind to port 443. Resolve this by:

Option 1: Use separate IP addresses. If the server has multiple IPs, bind IIS to one IP on port 443 and SSTP/RRAS to another IP on port 443. Bind each in HTTP.sys accordingly.

Option 2: Use a dedicated RRAS server that does not run IIS on port 443.

Option 3: For RRAS behind a firewall/NAT, forward TCP 443 from a separate public IP to the RRAS server’s internal IP. The RRAS server does not need port 443 to be reachable on a second interface.

Create Windows Firewall rules to allow SSTP inbound on the RRAS server if not automatically created:

New-NetFirewallRule -DisplayName "SSTP VPN Inbound" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 443 `
  -Action Allow `
  -Profile Any `
  -Description "Allow SSTP VPN connections"

RRAS also requires GRE protocol (IP protocol 47) for PPTP if you are running mixed VPN types. For SSTP-only deployments, only TCP 443 is needed, making it extremely firewall-friendly — most organizations allow outbound HTTPS from all workstations already.

Setting Up NPS for RADIUS Authentication

Install NPS on the designated RADIUS server:

Install-WindowsFeature -Name NPAS -IncludeManagementTools
netsh nps add registeredserver

Add the RRAS server as a RADIUS client in NPS. Open nps.msc, navigate to RADIUS Clients and Servers > RADIUS Clients, and add a new client entry with the RRAS server’s IP and the shared secret. Alternatively via netsh:

netsh nps add client name="RRAS-VPN01" address=192.168.1.10 sharedsecret=StrongRadiusSecret!2024

Create a Connection Request Policy that forwards VPN connection requests to NPS for processing (or if NPS is local, it processes them directly). Create a Network Policy that grants access to VPN-Users group members with MS-CHAPv2 or EAP authentication:

# Via netsh commands (scripting NPS policy creation)
netsh nps add np name="VPN Users Policy" processingorder=1 policysource=0 conditionid="0x3D" conditiondata="0" conditiondata="7" permit=1

In practice, NPS policy creation is most reliably done via the GUI or by exporting/importing NPS configuration XML. Export a working NPS config:

Export-NpsConfiguration -Path "C:BackupNPS-Config.xml"
# Import on another server:
Import-NpsConfiguration -Path "C:BackupNPS-Config.xml"

Creating a Windows VPN Connection for SSTP

On the client machine, create a VPN connection configured for SSTP. Via PowerShell:

Add-VpnConnection -Name "Contoso SSTP VPN" `
  -ServerAddress "vpn.contoso.com" `
  -TunnelType Sstp `
  -AuthenticationMethod MSChapv2 `
  -EncryptionLevel Required `
  -SplitTunneling $true `
  -RememberCredential $true `
  -PassThru

For EAP-TLS (certificate-based) authentication instead of MS-CHAPv2:

Add-VpnConnection -Name "Contoso SSTP EAP" `
  -ServerAddress "vpn.contoso.com" `
  -TunnelType Sstp `
  -AuthenticationMethod Eap `
  -EapConfigXmlStream (Get-Item "C:VPNEapConfig.xml") `
  -EncryptionLevel Required `
  -SplitTunneling $true

Add split tunnel routes so internal subnets go through the VPN:

Add-VpnConnectionRoute -ConnectionName "Contoso SSTP VPN" -DestinationPrefix 10.0.0.0/8
Add-VpnConnectionRoute -ConnectionName "Contoso SSTP VPN" -DestinationPrefix 172.16.0.0/12

Connect the VPN:

rasdial "Contoso SSTP VPN" username password

SSTP vs IKEv2 Comparison

IKEv2 is generally preferred over SSTP when clients have unrestricted internet access. IKEv2 supports MOBIKE (IKEv2 Mobility and Multihoming), which allows seamless reconnection when a client’s IP address changes (e.g., switching from Wi-Fi to cellular). This makes IKEv2 excellent for mobile users. IKEv2 has lower overhead than SSTP because it does not encapsulate traffic in HTTPS, resulting in better throughput and lower latency.

SSTP’s key advantage is port 443 traversal. In environments where only outbound HTTPS is allowed (strict corporate networks, hotels, restrictive public Wi-Fi), IKEv2 (UDP 500/4500) and L2TP/IPsec (UDP 500/4500) may be blocked while SSTP works fine. The Windows VPN client supports an “automatic” tunnel type that tries IKEv2 first and falls back to SSTP, giving you the best of both:

Add-VpnConnection -Name "Contoso Auto VPN" `
  -ServerAddress "vpn.contoso.com" `
  -TunnelType Automatic `
  -AuthenticationMethod MSChapv2 `
  -EncryptionLevel Required

Troubleshooting SSTP VPN Connections

The most common SSTP issues are certificate-related. If the client cannot validate the VPN server’s SSL certificate, the connection fails with “The certificate’s CN name does not match the passed value” or “The revocation function was unable to check revocation”. Check:

# Verify the certificate on the RRAS server
Get-ChildItem Cert:LocalMachineMy | Where-Object Subject -like "*vpn*" | Select-Object Subject, NotAfter, Thumbprint

# Test SSL certificate from client (run on client)
$Request = [System.Net.HttpWebRequest]::Create("https://vpn.contoso.com")
$Request.GetResponse()
$Request.ServicePoint.Certificate | Select-Object Subject, Issuer, GetExpirationDateString()

Enable RRAS tracing for detailed connection logs:

netsh ras set tracing * enabled
# Attempt VPN connection from client
# Review logs:
Get-ChildItem C:Windowstracing*.log | Sort-Object LastWriteTime -Descending | Select-Object -First 5
netsh ras set tracing * disabled

Check the RRAS event log on the server:

Get-WinEvent -LogName System | Where-Object ProviderName -like "*RemoteAccess*" | Select-Object -First 20 TimeCreated, Id, Message

Check active SSTP connections:

netsh ras show activeconn
Get-RemoteAccessConnectionStatistics | Where-Object {$_.TunnelType -eq "Sstp"} | Select-Object *

For connectivity issues where the tunnel establishes but traffic does not flow, check the routing table on both the RRAS server and the client, ensure IP forwarding is enabled on the RRAS server, and verify that the internal DNS server is reachable through the VPN tunnel.