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

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

Secure Socket Tunneling Protocol (SSTP) is a Microsoft VPN protocol that encapsulates Point-to-Point Protocol (PPP) traffic inside an HTTPS connection on TCP port 443. Because SSTP uses the same port as standard HTTPS web traffic, it works reliably in environments where UDP-based VPN protocols like IKEv2 (UDP 500/4500) and L2TP/IPsec (UDP 1701) are blocked by corporate firewalls, hotel networks, or carrier-grade NAT. Windows Server 2025 supports SSTP natively through the Routing and Remote Access Service (RRAS) role, and Windows 10/11 clients can connect using the built-in VPN client without any third-party software. This tutorial walks through the complete SSTP VPN server setup, including feature installation, RRAS configuration, certificate binding, Network Policy Server (NPS) authentication, client connection setup, and session monitoring.

When to Use SSTP

Choose SSTP when:

• Your remote users frequently connect from restrictive networks that block UDP traffic
• You need a simple VPN solution compatible with all Windows clients without additional software
• You have an existing public CA certificate (or can obtain one) for the VPN server’s FQDN
• You do not require certificate-based user authentication (SSTP uses credential-based auth by default, typically via NPS with MSCHAPv2 or PEAP)

SSTP has trade-offs: TCP-over-TCP can exhibit head-of-line blocking under packet loss, making it less efficient than UDP-based protocols for high-throughput workloads. For modern deployments where UDP is available, IKEv2 is preferred. SSTP remains the reliable fallback.

Prerequisites

• Windows Server 2025 with a public IP address or NAT port-forwarding on TCP 443
• A valid SSL/TLS certificate issued by a publicly trusted or enterprise CA, with a Subject Alternative Name matching the VPN server’s public FQDN (e.g., vpn.contoso.com)
• Active Directory domain with user accounts
• Network Policy Server (NPS) — either co-located on the RRAS server or on a separate server
• DNS record for the VPN FQDN resolving to the server’s public IP
• If using port 443 for SSTP, IIS must not be bound to port 443 on the same IP address — SSTP and HTTPS cannot share the same IP/port combination without SNI routing

Step 1 — Install the Remote Access Role

Install RRAS and its management tools on the VPN server. Include NPS if you will co-locate the RADIUS server on the same machine (acceptable for small deployments up to ~50 concurrent users).

# Install Remote Access with management tools
Install-WindowsFeature -Name RemoteAccess -IncludeManagementTools

# If co-locating NPS on the same server
Install-WindowsFeature -Name NPAS -IncludeManagementTools

# Verify features
Get-WindowsFeature -Name RemoteAccess, NPAS | Select-Object Name, InstallState

Step 2 — Configure RRAS for VPN

Initialize RRAS for VPN-only mode. Do not use the GUI wizard as it offers fewer options and is harder to repeat consistently.

# Configure RRAS for VPN
Install-RemoteAccess -VpnType Vpn

# Verify RRAS is running
Get-RemoteAccess | Select-Object VpnStatus, DAStatus

# Check the RRAS service
Get-Service RemoteAccess | Select-Object Name, Status, StartType

After initialization, configure the IP address pool that RRAS will assign to VPN clients. If you have DHCP integration configured, RRAS can request addresses from DHCP instead of a static pool.

# Configure a static IP address pool for VPN clients
$vpnConfig = Get-RemoteAccessConfiguration
Set-RemoteAccessIpFilter -ExternalInterface "Ethernet"

# Configure the RRAS IP address pool
# Replace with your internal subnet range allocated for VPN clients
netsh ras ip set addrassign method=pool
netsh ras ip set pool from=10.20.0.1 to=10.20.0.100

Step 3 — Bind the SSL Certificate for SSTP

SSTP requires a valid TLS certificate bound to the RRAS server. The certificate must be trusted by clients, which means it must be issued by a CA whose root is in the client’s Trusted Root Certification Authorities store. A self-signed certificate will cause connection errors on clients that do not have the certificate manually imported — this is not practical for production.

Import your certificate to the local machine certificate store and bind it to SSTP:

# Import the PFX certificate (if not already imported via AD CS auto-enrollment)
$certPassword = Read-Host -AsSecureString "Enter PFX password"
Import-PfxCertificate `
    -FilePath C:Certsvpn-contoso-com.pfx `
    -CertStoreLocation Cert:LocalMachineMy `
    -Password $certPassword

# Find the certificate thumbprint
$cert = Get-ChildItem -Path Cert:LocalMachineMy |
    Where-Object { $_.Subject -like "*vpn.contoso.com*" -and $_.HasPrivateKey } |
    Select-Object -First 1

Write-Host "Certificate thumbprint: $($cert.Thumbprint)"

# Bind the certificate to SSTP (this replaces any existing SSTP certificate binding)
Set-RemoteAccessSSTPConfiguration -Certificate $cert -PassThru

Verify the certificate is correctly bound:

Get-RemoteAccessSSTPConfiguration | Select-Object ServerCertificate

# Also verify via netsh
netsh http show sslcert ipport=0.0.0.0:443

Step 4 — Configure NPS for VPN Authentication

If NPS is installed on the same server as RRAS, register it with Active Directory so it can read user account properties including dial-in permission.

# Register NPS in Active Directory
netsh nps add registeredserver

# If using a remote NPS server, configure RRAS to forward auth requests to it
Add-RemoteAccessRadius `
    -ServerName NPS-SERVER01 `
    -SharedSecret "Str0ngSharedSecret!" `
    -Purpose Authentication `
    -Port 1812

In the NPS console (or via PowerShell), create a Connection Request Policy and Network Policy for VPN users. The Network Policy should include:

• Condition: Windows Groups = CONTOSOVPN-Users
• Authentication: Microsoft Encrypted Authentication version 2 (MS-CHAPv2) for credential-based auth, or PEAP for added security
• Constraints: optionally restrict connection time, client IP, or NAS port type to Virtual (VPN)
• Access: Grant access

# Export NPS configuration for backup and documentation
Export-NpsConfiguration -Path C:NPSnps-vpn-config.xml

# View registered RADIUS clients
netsh nps show client

Step 5 — Configure User Dial-in Permission

VPN access can be controlled at two levels: the NPS Network Policy (preferred) or per-user dial-in permissions in Active Directory Users and Computers. The recommended approach is to leave all user accounts set to Control access through NPS Network Policy and let the NPS group condition determine who can connect.

# Check a user's dial-in permission via PowerShell (AD module required)
Import-Module ActiveDirectory
Get-ADUser -Identity jsmith -Properties msNPAllowDialin |
    Select-Object Name, msNPAllowDialin

# Set to "Control access through NPS Network Policy" (null value)
Set-ADUser -Identity jsmith -Clear msNPAllowDialin

# Force allow (bypasses NPS policy — use carefully)
Set-ADUser -Identity jsmith -Replace @{msNPAllowDialin=$true}

Step 6 — Create VPN Connection on a Windows Client

Windows 10 and Windows 11 clients can connect to an SSTP VPN server using the built-in VPN client or via a PowerShell-deployed VPN profile.

# Create an SSTP VPN connection on the client (run on the client machine)
Add-VpnConnection `
    -Name "Contoso SSTP VPN" `
    -ServerAddress "vpn.contoso.com" `
    -TunnelType Sstp `
    -AuthenticationMethod MSChapv2 `
    -EncryptionLevel Required `
    -RememberCredential $true `
    -DnsSuffix "contoso.com" `
    -SplitTunneling $true

# Add split tunnel routes (only route internal subnets through the VPN)
Add-VpnConnectionRoute `
    -ConnectionName "Contoso SSTP VPN" `
    -DestinationPrefix "10.10.0.0/16"

# Connect
rasdial "Contoso SSTP VPN" username password

For domain-joined machines managed via Group Policy or SCCM, deploy the VPN connection via a logon script or ConfigMgr application.

Step 7 — Monitor Active VPN Sessions

Monitor active connections on the RRAS server to track connected users, session duration, and IP assignments.

# List active VPN sessions on the RRAS server
Get-RemoteAccessConnectionStatistics | Select-Object UserName, ClientIPAddress, `
    TunnelType, ConnectionDuration, BytesIn, BytesOut | Format-Table -AutoSize

# Get count of active connections
(Get-RemoteAccessConnectionStatistics).Count

# Disconnect a specific user session
Disconnect-VpnUser -UserName "CONTOSOjsmith"

# View RRAS event log for authentication events
Get-WinEvent -LogName "Security" -MaxEvents 50 |
    Where-Object { $_.Id -in 6272, 6273 } |
    Select-Object TimeCreated, Id, Message |
    Format-List

For SSTP specifically, also check the RRAS operational log:

Get-WinEvent -LogName "Microsoft-Windows-RemoteAccess-RemoteAccessServer/Operational" |
    Select-Object -First 20 TimeCreated, Id, LevelDisplayName, Message

SSTP Port Conflict with IIS

A common deployment issue occurs when IIS is also running on the same server and bound to port 443. SSTP requires exclusive access to TCP 443 on the RRAS server’s external IP. Solutions:

• Assign a dedicated IP address to RRAS (bind IIS to a different IP, RRAS to the VPN IP)
• Move IIS to a different server or port
• Use HTTP.sys SNI routing to share port 443 — this requires Windows Server 2025 and a supported configuration, and has limitations with some VPN clients

# Check what is listening on port 443
netstat -ano | findstr :443

# Check HTTP.sys SSL certificate bindings
netsh http show sslcert

Conclusion

SSTP VPN on Windows Server 2025 provides a reliable, firewall-friendly remote access solution that requires no client software beyond the built-in Windows VPN client. By installing RRAS, binding a publicly trusted SSL certificate, configuring NPS with group-based access policies, and deploying VPN connection profiles via PowerShell or SCCM, you build a complete remote access solution that works for users in the most restrictive network environments. Pair it with PowerShell-based session monitoring and Windows Event Log integration to maintain visibility over who is connected and when. For organizations moving toward modern management, consider layering SSTP as the fallback protocol within an Always On VPN deployment that prefers IKEv2 — giving your users the best performance when UDP is available and automatic failover to SSTP when it is not.