SSTP (Secure Socket Tunneling Protocol) is a popular choice for remote access VPNs on Windows because it tunnels PPP over HTTPS (TCP/443), traverses most firewalls and proxies, and integrates with Windows authentication. When SSTP fails, diagnosing the cause can be tricky: issues can be on the client, on the server (RRAS/Remote Access), in the TLS/certificate chain, or in network/firewall/NAT behavior. PowerShell provides a powerful, scriptable toolset to quickly gather diagnostics, run targeted tests and apply fixes at scale. This article walks you through practical, command-centric troubleshooting steps and automated checks you can run to resolve SSTP connection problems.

First principles: what to verify before deep diving

Before running commands, confirm these basic facts because many SSTP problems are environmental:

• The SSTP server is listening on TCP 443 and reachable from the client network.
• A valid server certificate (subject name matches public DNS name clients use) is bound for SSL on the server.
• RRAS (Remote Access) is configured to accept SSTP and is running.
• Client has correct VPN configuration (server name, authentication method, correct certs if using EAP/Smartcard).

Quick connectivity checks with PowerShell

Use these short tests first to rule out basic networking and TLS reachability problems.

Test TCP connectivity and TLS handshake

From the client, run:

Test-NetConnection -ComputerName vpn.yourdomain.com -Port 443 -InformationLevel Detailed

This verifies TCP connectivity and resolves DNS. If Test-NetConnection reports filtering or no route, inspect routing/firewall. To test an actual TLS handshake you can use PowerShell’s [Net.ServicePointManager], but a simpler approach is:

openssl s_client -connect vpn.yourdomain.com:443 -servername vpn.yourdomain.com

If OpenSSL is unavailable, you can use .NET to attempt an SSL connection and capture the server certificate:


$tcp = New-Object System.Net.Sockets.TcpClient('vpn.yourdomain.com',443) ;$ssl = New-Object System.Net.Security.SslStream($tcp.GetStream(),$false,{$true}); $ssl.AuthenticateAsClient('vpn.yourdomain.com'); $ssl.RemoteCertificate | Format-List


Get-ChildItem Cert:LocalMachineMy | Where-Object {$_.Subject -like 'vpn.yourdomain.com'} | Select-Object Subject, NotAfter, Thumbprint

Get-RemoteAccess | Format-List

To list active connections and stats:

Get-RemoteAccessConnectionStatistics

If RRAS is stopped, start it:

Start-Service RemoteAccess

Verify SSL certificate binding on TCP 443

SSTP relies on the server certificate bound to the HTTPS endpoint. Verify the binding:

netsh http show sslcert

Look for an entry with IP:port 0.0.0.0:443 and the expected certificate hash. If there’s no binding or the thumbprint is wrong, bind the correct cert:


netsh http add sslcert ipport=0.0.0.0:443 certhash=THUMBPRINT appid='{APP-GUID}' certstorename=MY


Replace THUMBPRINT with the certificate thumbprint (no spaces) and use any GUID for appid. You can get the thumbprint via:

Get-ChildItem Cert:LocalMachineMy | Where-Object {$_.Subject -like 'yourname'} | Select-Object Thumbprint

Check Schannel/TLS settings and cipher suites

SSTP needs compatible TLS versions and cipher suites. Use PowerShell to read registry Schannel settings:

Get-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Server'

If TLS1.2 is disabled, enable it by setting Enabled and DisabledByDefault appropriately. Restart the server after changes. Confirm supported ciphers using the IIS Crypto tool or by inspecting HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCryptographyConfigurationLocalDefaults0 entries.

Confirm certificate trust chain

A common SSTP failure is the client rejecting the server certificate due to an incomplete chain. On the server:

certutil -verify -urlfetch MyTHUMBPRINT

Also ensure intermediate CA certs are present in Intermediate Certification Authorities store and the root is trusted by clients.

Client-side diagnostics with PowerShell

On the client, gather these diagnostics to pinpoint failure reasons.

Inspect the VPN connection object

Use Windows 10/11 VPN cmdlets to inspect client config:

Get-VpnConnection -Name 'Your VPN Name' | Format-List

Get-ChildItem Cert:CurrentUserRoot | Where-Object {$_.Subject -like 'YourRootCA*'}

Network path and MTU/NAT issues

SSTP encapsulates PPP over TCP. Packet fragmentation, MTU, and certain NAT devices can break the session.

Test MTU and packet fragmentation

From client:

ping -f -l 1472 vpn.yourdomain.com

Decrease the payload size until no fragmentation is reported. If the path requires reduced MTU, configure the VPN server to adjust TCP MSS or set MSS clamping on edge devices. On RRAS, adjust routing or use Windows Firewall policies to clamp MSS via IPSec policies or by configuring NAT device.

Check for double NAT or proxy interference

Because SSTP uses HTTPS, some transparent proxies or SSL interceptors (security appliances performing TLS inspection) may terminate the TLS connection and present a different certificate. This will cause certificate chain errors. Test from a network without interception (e.g., mobile hotspot) to isolate the issue.

Common errors and targeted fixes

Certificate name mismatch or untrusted

Fixes:

• Bind the correct certificate to port 443 via netsh.
• Install intermediate and root CA certs on the server and client trust stores.
• Make sure clients use the same DNS name as the cert SAN.

TLS handshake failures

Fixes:

• Enable compatible TLS versions on both ends (prefer TLS 1.2).
• Update Windows to support modern cipher suites or adjust server cipher list.
• Check for middleboxes performing TLS interception and exclude SSTP from interception rules.

RRAS not accepting SSTP connections

Fixes:

• Ensure RemoteAccess service is running and SSTP is enabled: Start-Service RemoteAccess.
• Confirm RRAS has routing and remote access configured for VPN and SSTP is checked in wizard settings.
• Check licensing and NPS policies if using RADIUS; confirm authentication requests reach your NPS server: Get-RemoteAccessConnectionStatistics.

Automating checks: a compact PowerShell diagnostic script

Use this lightweight script to collect key SSTP diagnostics from a server or client quickly. Save as Gather-SSTPDiagnostics.ps1 and run elevated.

$Out = [ordered]@{}
$Out.Timestamp = (Get-Date)
$Out.TestNet = Test-NetConnection -ComputerName 'vpn.yourdomain.com' -Port 443 -InformationLevel Detailed
$Out.SSLBindings = netsh http show sslcert
$Out.RRASStatus = Get-Service RemoteAccess | Select-Object Name, Status
$Out.SSTPStats = try { Get-RemoteAccessConnectionStatistics } catch { $_.Exception.Message }
$Out.Certs = Get-ChildItem Cert:LocalMachineMy | Select-Object Subject, Thumbprint, NotAfter
$Out.Events = Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='RasSrv' ; StartTime=(Get-Date).AddHours(-2)} -MaxEvents 50 | Select-Object TimeCreated, Id, Message
$Out | ConvertTo-Json -Depth 5


Run the script and inspect the JSON for quick correlation between network, service, cert, and event log states.

When to escalate: server capture and vendor support

If the above steps don’t reveal the issue, collect a packet capture (on the server and client) during a failed attempt. Capture TLS handshake details and any TCP resets. On Windows, use the Microsoft Network Monitor or Message Analyzer (deprecated) or run netsh trace start capture=yes. Provide captures to vendors (VPN appliance, firewall vendor or Microsoft support) with timestamps and relevant event log entries.

Summary checklist for SSTP troubleshooting

• Confirm DNS points to the server and the certificate name matches DNS.
• Ensure SSL certificate is correctly bound to 0.0.0.0:443 with netsh.
• Verify RRAS/Remote Access service is running and SSTP is enabled.
• Confirm TLS versions and cipher suites are compatible; enable TLS 1.2+ where possible.
• Check client and server event logs for RasClient/RasSrv errors, capture error codes.
• Verify no SSL-intercepting proxy or middlebox is altering certificate chains.
• Test from a different network to exclude local ISP/NAT issues.
• Use packet captures for deep-dive analysis if handshakes show resets or malformed TLS messages.

Using PowerShell as your primary troubleshooting interface keeps checks repeatable and automatable across many servers and clients. The commands in this article equip you to identify the typical SSTP failure modes—certificate problems, TLS mismatches, RRAS configuration, firewall/NAT and MTU issues—and apply pragmatic fixes rapidly. For scripted environments, incorporate the diagnostic script into your management automation to produce consistent telemetry whenever SSTP incidents occur.

For further resources and practical guides on VPN deployment and debugging, see Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.