When using Windows Server Routing and Remote Access Service (RRAS) to terminate Always On VPN client connections, administrators can leverage the Secure Socket Tunneling Protocol (SSTP) VPN protocol for client-based VPN connections. SSTP is a Microsoft proprietary VPN protocol that uses Transport Layer Security (TLS) to secure connections between the client and the VPN gateway. SSTP provides some crucial advantages over IKEv2 in terms of operational reliability. It uses the TCP port 443, the standard HTTPS port, which is universally available and ensures Always On VPN connectivity even behind highly restrictive firewalls.
TLS Certificate
When configuring SSTP, the first thing to consider is the certificate installed on the server. A certificate with an RSA key is most common, but for SSTP, provisioning a certificate with an ECDSA key is recommended for optimal security and performance. See the following two articles regarding SSTP certificate requirements and ECDSA Certificate Signing Request (CSR) creation.
Always On VPN SSL Certificate Requirements for SSTP
Always On VPN ECDSA SSL Certificate Request for SSTP
TLS Configuration
Much like IKEv2, the default TLS security settings for SSTP are less than optimal. However, SSTP can provide excellent security with some additional configuration.
TLS Protocols
There are several deprecated TLS protocols enabled by default in Windows Server. These include SSLv3.0, TLS 1.0, and TLS 1.1. They should be disabled to improve security for TLS. To do this, open an elevated PowerShell window on the VPN server and run the following commands.
New-Item -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server\’ -Force
New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server\’ -Name Enabled -PropertyType DWORD -Value ‘0’
New-Item -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server\’ -Force
New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server\’ -Name Enabled -PropertyType DWORD -Value ‘0’
New-Item -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server\’ -Force
New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server\’ -Name Enabled -PropertyType DWORD -Value ‘0’
Cipher Suites
Many weak TLS cipher suites and enabled by default in Windows Server. To further enhance security and performance, they can be optimized using a tool such as IIS Crypto. For example, consider prioritizing cipher suites that use ECDHE and GCM with ECDSA to improve security. Also, remove ciphers that use AES-256 to enhance scalability and performance.
Note: AES-256 does not provide any additional practical security over AES-128. Details here.
PowerShell Script
I have published a PowerShell script on GitHub that performs security hardening and TLS cipher suite optimization to streamline the configuration TLS on Windows Server RRAS servers. You can download the script here.
Validation Testing
After running the script and restarting the server, visit the SSL Labs Server Test site to validate the configuration. You should receive an “A” rating, as shown here.
Note: An “A” rating is not achievable on Windows Server 2012 or Windows Server 2012 R2 when using an RSA TLS certificate. A TLS certificate using ECDSA is required to receive an “A” rating on these platforms.
Additional Information
Always On VPN SSL/TLS Certificate Requirements for SSTP
Always On VPN ECDSA SSL Certificate Request for SSTP
Qualys SSL Labs Server Test Site
Always On VPN Protocol Recommendations for Windows Server RRAS
Jeremy Noone
/ June 24, 2021Hey Richard,
This is a great follow up to the IKEv2 security hardening. Is there a way to reset everything in your script easily? Would I just set the registry keys back to 1? Do you have the original cipher suite order?
I ran the IIS Crypto tool on my existing VPN server a year or so ago and it completely broke it.
Richard M. Hicks
/ June 24, 2021Thanks! If you wanted to undo the changes my script makes, you can simply delete the registry keys it adds. Deleting the cipher suite list will result in the default cipher list used. IIS Crypto isn’t my favorite tool, but it does essentially what my script does. If you break something with their tool you can remove the same registry keys to restore functionality.
Mikael Hansen
/ December 23, 2021Hi Richard, great article as always!
I applied your script in a test environment but after applying it and restarting the server I could no longer establish SSTP connections. The client would simply attempt the connection and stall. the eventlog contains an error stating that “the first SSTP request was not send to the server. This could be because of connection issues or issues with a certificate” (loosely translated from Danish).
Would the changes made by the script require specific settings in the SSL certificate on the server or on the client (Using PEAP with user certificates)?
Richard M. Hicks
/ December 30, 2021No, you should be able to run the script on the VPN server and have it work with any TLS certificate that’s installed. What version of Windows Server are you running? I just fixed a bug with Windows Server 2022 recently that broke things. Perhaps deleting the registry key and downloading my latest script will work this time? Let me know!
Mikael Hansen
/ December 31, 2021Thanks for your reply Richard,
I’m running a Windows Server 2019 fully patched. Clients are Windows 10 pro and authentication is PEAP with user certificates.
I’ll try to rerun the script using the latest version and let you know as soon as I’ve been able to test it.
Richard M. Hicks
/ December 31, 2021Ok. Shouldn’t have been an issue with Windows Server 2019. Let me know what happens though if you delete that registry key then rerun my script.
Ayush Ludhwani
/ December 14, 2022Hi Rcihard,
My client has configured Always On VPN with SSTP and intermittently connectivity breaks down with event ID generating as 20255 which states: The following error occurred in the Point to Point Protocol module on port: VPN1-2035, UserName: [redacted]. The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.
Could you help on this with your suggestions?
Richard M. Hicks
/ December 14, 2022I would suggest looking at the event logs on the NPS server. Search for event ID 6273. It should provide some insight as to why the authentication attempt was rejected.
Ayush Ludhwani
/ December 19, 2022Client is using cisco ISE as Radius and not the Microsoft NPS.
Richard M. Hicks
/ December 19, 2022Ok. Have a look at the access logs on the ISE. It should give some indication as to why the authentication request was rejected.