All posts in category Encryption

Always On VPN SSTP Security Configuration

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

Microsoft SSTP Specification on MSDN

2 Comments

by Richard M. Hicks on June 21, 2021 • Permalink

Tagged Always On VPN, cryptography, ECDSA, Microsoft, Mobility, PowerShell, Remote Access, routing and remote access service, RRAS, RSA, Secure Socket Tunneling Protocol, security, SSL, SSTP, TLS, VPN, Windows, Windows 10, Windows Server

Posted by Richard M. Hicks on June 21, 2021

https://directaccess.richardhicks.com/2021/06/21/always-on-vpn-sstp-security-configuration/

Always On VPN IPsec Root Certificate Configuration Issue

When configuring a Windows Routing and Remote Access Service (RRAS) server to support Internet Key Exchange version 2 (IKEv2) VPN connections, it is essential for the administrator to define the root certification authority for which to accept IPsec security associations (SAs). Without defining this setting, the VPN server will accept a device certificate issued by any root certification authority defined in the Trusted Root Certification Authorities store. Details about configuring IKEv2 security and defining the root certification authority can be found here.

Multiple Root Certificates

Administrators may find that when they try to define a specific root certification authority, the setting may not be implemented as expected. This commonly occurs when there is more than one root certificate in the Trusted Root Certification Authorities store for the same PKI.

Certificate Selection

When running the PowerShell command Set-VpnAuthProtocol to define the root certification authority, PowerShell may ignore the administrator-defined certificate and choose a different one, as shown here. This will result in failed IPsec VPN connections from Windows 10 Always On VPN clients using IKEv2.

Certificate Publishing

This issue can occur when root certification authority certificates are published using Active Directory group policy. It appears that Windows prefers Active Directory group policy published certificates over those published directly in the Certification Authorities Container in Active Directory. To resolve this issue, remove any group policy objects that are publishing root certification authority certificates and ensure those root certificates are published in the Certification Authorities container in Active Directory.

PowerShell Script

A PowerShell script to configure this setting that can be found in my Always On VPN GitHub repository here. I have updated this script to validate the defined root certification authority certificate and warn the user if it does not match.

Additional Information

Set-Ikev2VpnRootCertificate.ps1 PowerShell script on GitHub

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN IKEv2 Load Balancing and NAT

Windows 10 Always On VPN IKEv2 Features and Limitations

Windows 10 Always On VPN IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 Certificate Requirements

Always On VPN SSTP Certificate Binding Error

When configuring a Windows Server with the Routing and Remote Access Service (RRAS) role to support Windows 10 Always On VPN connections, the administrator may encounter the following error message when installing or updating the TLS certificate used for Secure Socket Tunneling Protocol (SSTP) connections.

“The thumbprint (cert hash) of the certificate used for Secure Socket Tunneling Protocol (SSTP) is different than the certificate bound to the Web listener (HTTP.sys). Configure SSTP to use the default certificate or the certificate bound to SSL. You can configure web server applications to use the same certificate used by SSTP.”

IIS Binding

Most commonly this error can occur if an administrator mistakenly binds a TLS certificate directly in IIS. To resolve this problem, open the IIS management console (inetmgr.exe), navigate to the Default Web Site and click Bindings in the Actions section. Highlight the HTTPS binding and click Remove. Once complete, open an elevated command window and run the iisreset.exe command.

Netsh

In some instances, the administrator may find no certificate bindings in the IIS management console. However, a certificate binding may still be present. To confirm, open an elevated command window and run the following command.

netsh.exe http show sslcert

Remove existing certificate binding by running the following commands.

netsh.exe http delete sslcert ipport=0.0.0.0:443
netsh.exe http delete sslcert ipport=[::]:443

SSTP Configuration

When configuring SSTP in RRAS for Always On VPN, certificate assignment should always be performed using the Routing and Remote Access management console (rrasmgmt.msc). No changes are required to be made in the IIS management console for SSTP.

Additional Information

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

Windows 10 Always On VPN SSTP Load Balancing with Citrix NetScaler ADC Load Balancer

Windows 10 Always On VPN SSTP Load Balancing with Kemp LoadMaster Load Balancer

Windows 10 Always On VPN SSTP Load Balancing with F5 BIG-IP Load Balancer

7 Comments

by Richard M. Hicks on August 31, 2020 • Permalink

Posted by Richard M. Hicks on August 31, 2020

https://directaccess.richardhicks.com/2020/08/31/always-on-vpn-sstp-certificate-binding-error/

Always On VPN Split vs. Force Tunneling

During the planning phase of a Windows 10 Always On VPN implementation the administrator must decide between two tunneling options for VPN client traffic – split tunneling or force tunneling. When split tunneling is configured, only traffic for the on-premises network is routed over the VPN tunnel. Everything else is sent directly to the Internet. With force tunneling, all client traffic, including Internet traffic, is routed over the VPN tunnel. There’s been much discussion recently on this topic, and this article serves to outline the advantages and disadvantages for both tunneling methods.

Force Tunneling

Force tunneling is typically enabled to meet the following requirements.

Visibility and Control

By routing all the client’s Internet traffic over the VPN tunnel, administrators can inspect, filter, and log Internet traffic using existing on-premises security solutions such as web proxies, content filters, or Next Generation Firewalls (NGFW).

Privacy

Enabling force tunneling ensures privacy and protection of all Internet communication. By routing all Internet traffic over the VPN, administrators can be certain that all communication from the Always On VPN client is encrypted, even when clients access unencrypted web sites or use untrusted or insecure wireless networks.

Force Tunneling Drawbacks

While configuring force tunneling for Always On VPN has some advantages, it comes with some serious limitations as well.

Poor User Experience

User experience is often degraded when all Internet traffic is routed over the VPN. These suboptimal network paths increase latency, and VPN encapsulation and encryption overhead increase fragmentation, leading to reduced throughput. Most Internet traffic is already encrypted in some form, and encrypting traffic that is already encrypted makes the problem even worse. In addition, force tunneling short-circuits geographic-based Content Delivery Networks (CDNs) further reducing Internet performance. Further, location-based services are often broken which can lead to improper default language selection or inaccurate web search results.

Increased Resource Consumption

Additional resources may need to be provisioned to support force tunneling. With corporate and Internet traffic coming over the VPN, more CPU, memory, and network resources may be required. Deploying additional VPN servers and higher throughput load balancers to support the increase in network traffic may also be necessary. Force tunneling also places higher demands on Internet Service Provider (ISP) links to the corporate datacenter.

Split Tunneling

The alternative to force tunneling is “split tunneling”. With split tunneling configured, only traffic destined for the internal corporate network is routed over the VPN. All other traffic is sent directly to the Internet. Administrators define IP networks that should be routed over the VPN, and those networks are added to the routing table on the VPN client.

Security Enforcement

The challenge of providing visibility and control of Internet traffic with split tunneling enabled can be met using a variety of third-party security solutions. Microsoft Defender ATP recently introduced support for web content filtering. Also, there are numerous cloud-based security offerings from many vendors that allow administrators to monitor and control client-based Internet traffic. Zscaler and Cisco Umbrella are two popular solutions, and no doubt there are many more to choose from.

Recommendations

The general guidance I provide customers is to use split tunneling whenever possible, as it provides the best user experience and reduces demands on existing on-premises infrastructure. Enabling split or force tunneling is ultimately a design decision that must be made during the planning phase of an Always On VPN implementation project. Both configurations are supported, and they each have their merits.

In today’s world, with many applications accessible via public interfaces, force tunneling is an antiquated method for providing visibility and control for managed devices in the field. If required, investigate the use of Microsoft or other third-party solutions that enforce security policy in place without the requirement to backhaul client Internet traffic to the datacenter over VPN for inspection, logging, and filtering.

Additional Information

Whitepaper: Enhancing VPN Performance at Microsoft

Whitepaper: How Microsoft Is Keeping Its Remote Workforce Connected

Microsoft Defender ATP Web Content Filtering

14 Comments

by Richard M. Hicks on April 14, 2020 • Permalink

Posted by Richard M. Hicks on April 14, 2020

https://directaccess.richardhicks.com/2020/04/14/always-on-vpn-split-vs-force-tunneling/

Always On VPN Device Tunnel Only Deployment Considerations

Recently I wrote about Windows 10 Always On VPN device tunnel operation and best practices, explaining its common uses cases and requirements, as well as sharing some detailed information about authentication, deployment recommendations, and best practices. I’m commonly asked if deploying Always On VPN using the device tunnel exclusively, as opposed to using it to supplement the user tunnel, is supported or recommended. I’ll address those topics in detail here.

Device Tunnel Only?

To start, yes, it is possible to deploy Windows 10 Always On VPN using only the device tunnel. In this scenario the administrator will configure full access to the network instead of limited access to domain infrastructure services and management servers.

Is It Recommended?

Generally, no. Remember, the device tunnel was designed with a specific purpose in mind, that being to provide pre-logon network connectivity to support scenarios such as logging on without cached credentials. Typically, the device tunnel is best used for its intended purpose, which is providing supplemental functionality to the user tunnel.

Deployment Considerations

The choice to implement Always On VPN using only the device tunnel is an interesting one. There are some potential advantages to this deployment model, but it is not without some serious limitations. Below I’ve listed some of the advantages and disadvantages to deploying the device tunnel alone for Windows 10 Always On VPN.

Advantages

Using the device tunnel alone does have some compelling advantages over the standard two tunnel (device tunnel/user tunnel) deployment model. Consider the following.

Single VPN Connection – Deploying the device tunnel alone means a single VPN connection to configure, deploy, and manage on the client. This also results in less concurrent connections and, importantly, less IP addresses to allocate and provision.
Reduced Infrastructure – The device tunnel is authenticated using only the device certificate. This certificate check is performed directly on the Windows Server Routing and Remote Access Service (RRAS) VPN server, eliminating the requirement to deploy Network Policy Server (NPS) servers for authentication.
User Transparency – The device tunnel does not appear in the modern Windows UI. The user will not see this connection if they click on the network icon in the notification area. In addition, they will not see the device tunnel connection in the settings app under Network & Internet > VPN. This prevents casual users from playing with the connection settings, and potentially deleting the connection entirely. It’s not that they can’t delete the device tunnel however, it’s just not as obvious.
Simplified Deployment – Deploying the device tunnel is less complicated than deploying the user tunnel. The device tunnel is provisioned once to the device and available to all users. This eliminates the complexity of having to deploy the user tunnel in each individual user’s profile.

Disadvantages

While there are some advantages to using the device tunnel by itself, this configuration is not without some serious limitations. Consider the following.

IKEv2 Only – The device tunnel uses the IKEv2 VPN protocol exclusively. It does not support SSTP. While IKEv2 is an excellent protocol in terms of security, it is commonly blocked by firewalls. This will prevent some users from accessing the network remotely depending on their location.
Limited OS Support – The device tunnel is only supported on Windows 10 Enterprise edition clients, and those clients must be joined to a domain. Arguably the device tunnel wouldn’t be necessary if the client isn’t domain joined, but some organizations have widely deployed Windows 10 Professional, which would then preclude them from being able to use the device tunnel.
Machine Certificate Authentication Only – The device tunnel is authenticated using only the certificate issued to the device. This means anyone who logs on to the device will have full access to the internal network. This may or may not be desirable, depending on individual requirements.
No Mutual Authentication – When the device tunnel is authenticated, the server performs authentication of the client, but the client does not authenticate the server. The lack of mutual authentication increases the risk of a man-in-the-middle attack.
CRL Checks Not Enforced – By default, RRAS does not perform certificate revocation checking for device tunnel connections. This means simply revoking a certificate won’t prevent the device from connecting. You’ll have to import the client’s device certificate into the Untrusted Certificates certificate store on each VPN server. Fortunately, there is a fix available to address this limitation, but it involves some additional configuration. See Always On VPN Device Tunnel and Certificate Revocation for more details.
No Support for Azure Conditional Access – Azure Conditional Access requires EAP authentication. However, the device tunnel does not use EAP but instead uses a simple device certificate check to authenticate the device.
No Support for Multifactor Authentication – As the device tunnel is authenticated by the RRAS VPN server directly and authentication requests are not sent to the NPS server, it is not possible to integrate MFA with the device tunnel.
Limited Connection Visibility – Since the device tunnel is designed for the device and not the user it does not appear in the list of active network connections in the Windows UI. There is no user-friendly connection status indicator, although the connection can be viewed using the classic network control panel applet (ncpa.cpl).

Summary

The choice to deploy Windows 10 Always On VPN using the device tunnel alone, or in conjunction with the user tunnel, is a design choice that administrators must make based on their individual requirements. Using the device tunnel alone is supported and works but has some serious drawbacks and limitations. The best experience will be found using the device tunnel as it was intended, as an optional component to provide pre-logon connectivity for an existing Always On VPN user tunnel.

Additional Information

Windows 10 Always On VPN Device Tunnel with Azure VPN Gateway

Windows 10 Always On VPN Device Tunnel and Certificate Revocation

Windows 10 Always On VPN Device Tunnel Configuration with Microsoft Intune

Windows 10 Always On VPN Device Tunnel Does Not Connect Automatically

Windows 10 Always On VPN Device Tunnel Missing in Windows 10 UI

Deleting a Windows 10 Always On VPN Device Tunnel

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN IKEv2 Features and Limitations

59 Comments

by Richard M. Hicks on April 6, 2020 • Permalink

Posted by Richard M. Hicks on April 6, 2020

https://directaccess.richardhicks.com/2020/04/06/always-on-vpn-device-tunnel-only-deployment-considerations/

Always On VPN Device Tunnel with Azure VPN Gateway

Always On VPN is infrastructure independent, which allows for many different deployment scenarios including on-premises and cloud-based. In Microsoft Azure, the Azure VPN gateway can be configured to support Windows 10 Always On VPN client connections in some scenarios. Recently I wrote about using the Azure VPN gateway for Always On VPN user tunnels. In this post I’ll describe how to configure the Azure VPN gateway to support an Always On VPN device tunnel.

Limitations

There are a few crucial limitations that come with using the Azure VPN gateway for Always On VPN. Importantly, the Azure VPN gateway can support either user tunnels or device tunnels, not both at the same time. In addition, Azure supports only a single VPN gateway per VNet, so deploying an additional VPN gateway in the same VNet to support Always On VPN user tunnels is not an option.

Root CA Certificate

The Always On VPN device tunnel is authenticated using a machine certificate issued to domain-joined Windows 10 Enterprise edition clients by the organization’s internal Certification Authority (CA). The CA’s root certificate must be uploaded to Azure for the VPN gateway to authorize device tunnel connections. The root CA certificate can be exported using the Certification Authority management console (certsrv.msc) or via the command line.

Export Certificate – GUI

Follow the steps below to export a root CA certificate using the Certification Authority management console.

1. On the root CA server, open the Certification Authority management console.
2. Right-click the CA and choose Properties.
3. Select the CA server’s certificate and choose View Certificate.
4. Select the Details tab and click Copy to File.
5. Click Next.
6. Choose Base-64 encoded X.509 (.CER).

7. Click Next.
8. Enter a location to save the file to.
9. Click Next, Finish, and Ok.

Export Certificate – Command Line

Follow the steps below to export a root CA certificate using the command line.

1. On the root CA server, open an elevated command window (not a PowerShell window).
2. Enter certutil.exe -ca.cert root_certificate.cer.
3. Enter certutil.exe -encode root.cer root_certificate_base64.cer.

Copy Public Key

1. Open the saved root certificate file using Notepad.
2. Copy the file contents between the BEGIN CERTIFICATE and END CERTIFICATE tags, as shown here. Use caution and don’t copy the carriage return at the end of the string.

Point-to-Site Configuration

The Azure VPN gateway must be deployed as a Route-Based gateway to support point-to-site VPN connections. Detailed requirements for the gateway can be found here. Once the VPN gateway has been provisioned, follow the steps below to enable point-to-site configuration for Always On VPN device tunnels.

1. In the navigation pane of the Azure VPN gateway settings click Point-to-site configuration.
2. Click the Configure now link and specify an IPv4 address pool to be assigned to VPN clients. This IP address pool must be unique in the organization and must not overlap with an IP address ranges defined in the Azure virtual network.
3. From the Tunnel type drop-down list select IKEv2.
4. In the Root certificates section enter a descriptive name for the certificate in the Name field.
5. Copy and paste the Base64 encoded public key copied previously into the Public certificate data field.
6. Click Save to save the configuration.

VPN Client Configuration

To support the Always On VPN device tunnel, the client must have a certificate issued by the internal CA with the Client Authentication Enhanced Key Usage (EKU). Detailed guidance for deploying a Windows 10 Always On VPN device tunnel can be found here.

Download VPN Configuration

1. Click Point-to-site configuration.
2. Click Download VPN client.
3. Click Save.
4. Open the downloaded zip file and extract the VpnSettings.xml file from the Generic folder.
5. Copy the FQDN in the VpnServer element in VpnSettings.xml. This is the FQDN that will be used in the template VPN connection and later in ProfileXML.

Create a Test VPN Connection

It is recommended to create a test VPN connection to perform validation testing of the Azure VPN gateway before provisioning an Always On VPN device tunnel broadly. On a domain-joined Windows 10 enterprise client, create a new VPN connection using IKEv2 with machine certificate authentication. Use the VPN server FQDN copied from the VpnSettings.xml file previously.

Create an Always On VPN Connection

Once the VPN has been validated using the test profile created previously, an Always On VPN profile can be created and deployed using Intune, SCCM, or PowerShell. The following articles can be used for reference.

Deploy Always On VPN device tunnel using PowerShell

Deploy Always On VPN device tunnel using Intune

IKEv2 Security Configuration

The default IKEv2 security parameters used by the Azure VPN gateway are better than Windows Server, but the administrator will notice that a weak Diffie-Hellman (DH) key (Group 2 – 1024 bit) is used during IPsec phase 1 negotiation.

Use the following PowerShell commands to update the default IKEv2 security parameters to recommended baseline defaults, including 2048-bit keys (DH group 14) and AES-128 for improved performance.

Connect-AzAccount
Select-AzSubscription -SubscriptionName [Azure Subscription Name]

$Gateway = [Gateway Name]
$ResourceGroup = [Resource Group Name]

$IPsecPolicy = New-AzVpnClientIpsecParameter -IpsecEncryption AES128 -IpsecIntegrity SHA256 -SALifeTime 28800 -SADataSize 102400000 -IkeEncryption AES128 -IkeIntegrity SHA256 -DhGroup DHGroup14 -PfsGroup PFS14

Set-AzVpnClientIpsecParameter -VirtualNetworkGatewayName $Gateway -ResourceGroupName $ResourceGroup -VpnClientIPsecParameter $IPsecPolicy

Note: Be sure to update the cryptography settings on the test VPN connection and in ProfileXML for Always On VPN connections to match the new VPN gateway settings. Failing to do so will result in an IPsec policy mismatch error.

Additional Information

Windows 10 Always On VPN User Tunnel with Azure VPN Gateway

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN IKEv2 Features and Limitations

28 Comments

by Richard M. Hicks on January 6, 2020 • Permalink

Posted by Richard M. Hicks on January 6, 2020

https://directaccess.richardhicks.com/2020/01/06/always-on-vpn-device-tunnel-with-azure-vpn-gateway/

Always On VPN Error Code 858

When configuring Windows 10 Always On VPN using Extensible Authentication Protocol (EAP), the administrator may encounter a scenario in which the client connection fails. The event log will include an event ID 20227 from the RasClient source that includes the following error message.

“The user [domain\username] dialed a connection named [connection name] which has failed. The error code returned on failure is 858.”

RasClient Error 858

RasClient error code 858 translates to ERROR_EAP_SERVER_CERT_EXPIRED. Intuitively, this indicates that the Server Authentication certificate installed on the Network Policy Server (NPS) has expired. To resolve this issue, renew the certificate on the NPS server.

Additional Information

Windows 10 Always On VPN Network Policy Server (NPS) Load Balancing

Windows 10 Always On VPN and Windows Server 2019 NPS Bug

Windows 10 Always On VPN Error Code 864

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

A Windows Server with the Network Device Enrollment Service (NDES) role can be provisioned on-premises to support certificate deployment for non-domain Windows 10 Always On VPN clients. In addition, the Microsoft Intune Connector must be installed and configured on the NDES server to allow Intune-managed clients to request and receive certificates from the on-premises Certification Authority (CA) server.

Setup Wizard Ended Prematurely

When installing the Microsoft Intune Connector, the administrator may encounter a scenario where the setup wizard fails with the following error message.

“Microsoft Intune Connector Setup Wizard ended prematurely because of an error. Your system has not been modified. To install this program at a later time, run Setup Wizard again. Click the Finish button to exit the Setup Wizard.”

Cryptographic Service Provider

This error can occur if the NDES server certificate template is configured to use the Key Storage Provider cryptography service provider (CSP). When configuring the certificate template for the NDES server, the Legacy Cryptography Service Provider must be used, as shown here.

Additional Information

Deploying Windows 10 Always On VPN with Intune using Custom ProfileXML

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Deploying Windows 10 Always On VPN with Microsoft Intune

8 Comments

by Richard M. Hicks on November 11, 2019 • Permalink

Posted by Richard M. Hicks on November 11, 2019

https://directaccess.richardhicks.com/2019/11/11/microsoft-intune-ndes-connector-setup-wizard-ended-prematurely/

Always On VPN Device Tunnel and Certificate Revocation

Recently I wrote about denying access to Windows 10 Always On VPN users or computers. In that post I provided specific guidance for denying access to computers configured with the device tunnel. To summarize, the process involved exporting the device certificate from the issuing Certification Authority (CA) server and placing it in the Untrusted Certificates certificate store on each VPN server. In theory, simply revoking the device certificate should be all that’s required to prevent device tunnel connections.

Revocation Check Failure

As it turns out, a bug in Windows Server Routing and Remote Access prevents this from working as expected. Windows Server 2012 R2, 2016, and 2019 all fail to check the Certificate Revocation List (CRL) for IKEv2 VPN connections using machine certificate authentication (for example an Always On VPN device tunnel).

Updates for Windows Server

Microsoft has released fixes to support device tunnel certificate revocation for the following operating systems.

Windows Server 2019 – KB4505658 (build 17763.652)

Windows Server 2016 – KB4503294 (build 14393.3053)

Windows Server 2012/R2 – Will not be updated.

Enable Revocation Check

Additional configuration is required to enable support for CRL checking. Microsoft published guidance for configuring CRL revocation checks for IKEv2 VPN connections using machine certificate authentication here. Specifically, administrators must enable the RootCertificateNameToAccept parameter and set a registry key to enable this functionality.

Open an elevated PowerShell window and run the following commands to enable CRL checking for IKEv2 VPN connections using machine certificate authentication.

$Thumbprint = ‘Root CA Certificate Thumbprint’
$RootCACert = (Get-ChildItem -Path cert:\LocalMachine\root | Where-Object {$_.Thumbprint -eq $Thumbprint})
Set-VpnAuthProtocol -RootCertificateNameToAccept $RootCACert -PassThru

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\’ -Name CertAuthFlags -PropertyTYpe DWORD -Value ‘4’ -Force

Restart-Service RemoteAccess -PassThru

A PowerShell script to update the RootCertificateNameToAccept parameter on multiple VPN servers can be found here.

Revoking Certificates

To prevent a Windows 10 Always On VPN device tunnel connection, the administrator must first revoke the certificate on the issuing CA. Next, open an elevated command window an enter the following commands. Repeat these steps on each VPN server in the enterprise.

certutil -urlcache * delete
certutil -setreg chain\ChainCacheResyncFiletime @now

Additional Information

Denying Access to Windows 10 Always On VPN Users or Computers

Blocking VPN Clients that use Revoked Certificates

PowerShell Script to Configure RootCertificateNameToAccept on GitHub

34 Comments

by Richard M. Hicks on June 20, 2019 • Permalink

Posted by Richard M. Hicks on June 20, 2019

https://directaccess.richardhicks.com/2019/06/20/always-on-vpn-device-tunnel-and-certificate-revocation/

Always On VPN SSTP Load Balancing with F5 BIG-IP

The Windows Server Routing and Remote Access Service (RRAS) includes support for the Secure Sockets Tunneling Protocol (SSTP), which is a Microsoft proprietary VPN protocol that uses SSL/TLS for security and privacy of VPN connections. The advantage of using SSTP for Always On VPN is that it is firewall friendly and ensures consistent remote connectivity even behind highly restrictive firewalls.

Load Balancing SSTP

In a recent post, I described some of the use cases and benefits of SSTP load balancing as well as the offloading of TLS for SSTP VPN connections. Using a load balancer for SSTP VPN connections increases scalability, and offloading TLS for SSTP reduces resource utilization and improves performance for VPN connections. There are positive security benefits too.

Configuration

Enabling load balancing for SSTP on the F5 BIG-IP load balancer is fundamentally similar to load balancing HTTPS web servers. However, there are a few subtle but important differences.

Default Monitor

The default HTTP and HTTPS monitors on the F5 will not accurately reflect the health of the SSTP service running on the RRAS server. In addition, using a simple TCP port monitor could yield unexpected results. To ensure accurate service status monitoring, a new custom monitor must be created to validate the health of the SSTP service.

Custom SSTP Monitor

Open the F5 BIG-IP management console and follow the steps below to create and assign a new custom monitor for SSTP.

Create Monitor

1. In the navigation tree highlight Local Traffic.
2. Click Monitors.
3. Click Create.

4. Enter a descriptive name in the Name field and from the Type drop-down list choose HTTP if TLS offload is enabled, or HTTPS if it is not.
5. In the Send String field enter HEAD /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ HTTP/1.1\r\nHost:r\nConnection: Close\r\n\r\n.
6. In the Receive String field enter HTTP/1.1 401.
7. Click Finished.

Assign Monitor

1. Below Local Traffic click Pools.
2. Click on the SSTP VPN server pool.
3. In the Health Monitors section select the SSTP VPN health monitor from the Available list and make it Active.
4. Click Update.

CLI Configuration

If you prefer to configure the SSTP VPN monitor using the F5’s Command Line Interface (CLI), you can download the monitor configuration from my GitHub here.

TLS Offload

It is generally recommended that TLS offload not be enabled for SSTP VPN. However, if TLS offload is desired, it is configured in much the same way as a common HTTPS web server. Specific guidance for enabling TLS offload on the F5 BIG-IP can be found here. Details for configuring RRAS and SSTP to support TLS offload can be found here.

Certificates

When enabling TLS offload for SSTP VPN connections it is recommended that the public SSL certificate be installed on the RRAS server, even though TLS processing will be handled on the F5 and HTTP will be used between the F5 and the RRAS server. If installing the public SSL certificate on the RRAS server is not an option, additional configuration will be required. Specifically, TLS offload for SSTP must be configured using the Enable-SSTPOffload PowerShell script, which can be found here.

Once the script has been downloaded, open an elevated PowerShell command window and enter the following command.

Enable-SSTPOffload -CertificateHash [SHA256 Certificate Hash of Public SSL Certificate] -Restart

Example:

Enable-SSTPOffload -CertificateHash “C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2” -Restart

Re-Encryption

When offloading TLS for SSTP VPN connections, all traffic between the F5 and the RRAS server will be sent in the clear using HTTP. In some instances, TLS offload is required only for traffic inspection, not performance gain. In this scenario the F5 will be configured to terminate and then re-encrypt connections to the RRAS server. When terminating TLS on the F5 and re-encrypting connections to the RRAS server is required, the same certificate must be used on both the F5 and the RRAS server. Using different certificates on the RRAS server and the load balancer is not supported.

Additional Information

Windows 10 Always On VPN SSTP Load Balancing and SSL Offload

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

Windows 10 Always On VPN ECDSA SSL Certificate Request for SSTP

Windows 10 Always On VPN SSTP Connects then Disconnects

Windows 10 Always On VPN Load Balancing Deployment Guide for Kemp Load Balancers

13 Comments

by Richard M. Hicks on June 17, 2019 • Permalink

Posted by Richard M. Hicks on June 17, 2019

https://directaccess.richardhicks.com/2019/06/17/always-on-vpn-sstp-load-balancing-with-f5-big-ip/

Search for:
DirectAccess Book
NetMotion Mobility

DirectAccess-like Remote Access for Windows, Mac, iPhone, iPad, and Android

Learn More!
Recent Posts
Always On VPN Resources
DirectAccess Resources

Awards

Consulting

Connect

Mailing List

RSS Feed

Archives

Categories

Tag Cloud

All posts in category Encryption

TLS Certificate

TLS Configuration

TLS Protocols

Cipher Suites

PowerShell Script

Validation Testing

Additional Information

Share this:

Like this:

Multiple Root Certificates

Certificate Selection

Certificate Publishing

PowerShell Script

Additional Information

Share this:

Like this:

IIS Binding

Netsh

SSTP Configuration

Additional Information

Share this:

Like this:

Force Tunneling

Visibility and Control

Privacy

Force Tunneling Drawbacks

Poor User Experience

Increased Resource Consumption

Split Tunneling

Security Enforcement

Recommendations

Additional Information

Share this:

Like this:

Device Tunnel Only?

Is It Recommended?

Deployment Considerations

Advantages

Disadvantages

Summary

Additional Information

Share this:

Like this:

Limitations

Root CA Certificate

Export Certificate – GUI

Export Certificate – Command Line

Copy Public Key

Point-to-Site Configuration

VPN Client Configuration

Download VPN Configuration

Create a Test VPN Connection

Create an Always On VPN Connection

IKEv2 Security Configuration

Additional Information

Share this:

Like this:

RasClient Error 858

Additional Information

Share this:

Like this:

Setup Wizard Ended Prematurely

Cryptographic Service Provider

Additional Information

Share this:

Like this:

Revocation Check Failure

Updates for Windows Server

Enable Revocation Check

Revoking Certificates

Additional Information