Always On VPN and Third Party VPN Devices

Always On VPN and Third Party VPN DevicesOne of the most important advantages Windows 10 Always On VPN has over DirectAccess is infrastructure independence. That is, Always On VPN does not rely exclusively on a Windows Server infrastructure to support Always On VPN connections. Always On VPN will work with many third-party firewalls and VPN devices, as long as they meet some basic requirements.

Advantages

Third-party firewalls or VPN devices offer some important advantages over Windows Servers running the Routing and Remote Access Services (RRAS), both in terms of security and performance.

Security

Dedicated security devices (physical or virtual) provide better security than a common Windows server. They commonly run specialized, security-hardened operating systems that are highly secure and resistant to attack. In addition, these solutions typically allow the administrator to define policy to restrict access to internal resources and do so in a centralized way. This is often easier to implement and manage than using traffic filters on the client side. They often include advanced security features such as URL filtering and malware inspection to better protect remote clients. Some solutions include Hardware Security Module (HSM) integration to further enhance security.

Performance

Purpose-built solutions often provide better throughput and performance than do Windows Servers by virtue of their proprietary operating systems. This allows for better network throughput and the ability to support many more connections per device.

Disadvantages

The main drawbacks for using a third-party device are cost and administrative overhead. Third-party solutions must be acquired, for which there is typically a non-trivial cost associated. They often need additional per-user licensing. In addition, many of these solutions require specialized skill sets to implement, manage, and support which could further increase the overall cost of the solution.

Interoperability Requirements

Any firewall or VPN device can be used for Always On VPN as long as they support the Internet Key Exchange version 2 (IKEv2) VPN protocol for remote access connections. Most modern firewalls today support IKEv2, but some (such as the Sophos XG firewall) do not. Check with your vendor to validate support.

Native Client

If the firewall or VPN device supports IKEv2 for remote access connections, the native Windows VPN provider can be used to establish an Always On VPN connection. The native provider is used when the Always On VPN ProfileXML is configured using the NativeProfile element.

Plug-In VPN Client

One crucial drawback to using IKEv2 is that it is commonly blocked by firewalls. Many third-party VPN vendors offer a plug-in client that enables support for TLS-based transport, which is more firewall friendly than IKEv2. Plug-in VPN providers are available in the Microsoft store.

Below is a current list of available third-party plug-in providers for Windows 10. Notably absent from this list is Cisco. Hopefully they will add support for a plug-in client soon. 🙂

  • Check Point Capsule
  • F5 Access
  • Fortinet Forticlient
  • Palo Alto GlobalProtect
  • Pulse Secure
  • SonicWall Mobile Connect

Always On VPN and Third Party VPN Devices

Note: Win32 VPN client applications from third-party vendors are not supported with Windows 10 Always On VPN.

Additional Information

What is the Difference Between DirectAccess and Always On VPN?

5 Things DirectAccess Administrators Should Know about Always On VPN

3 Important Advantages of Always On VPN over DirectAccess

Always On VPN and DirectAccess Scripts and Sample Files on GitHub

Always On VPN and DirectAccess Scripts and Sample Files on GitHubIf you’re looking for specialized configuration scripts for Windows 10 Always On VPN, Windows Server Routing and Remote Access Service (RRAS), or DirectAccess then have a look at my GitHub page! There I’ve uploaded a few tools I’ve created (with the help of my good friend Jeff Hicks!) along with some sample ProfileXML files. Here’s a sample of what you’ll find there today.

Always On VPN

This repository includes PowerShell scripts and sample ProfileXML files used for configuring Windows 10 Always On VPN. These scripts have been adopted from those provided by Microsoft and modified to work with a separate XML file. These scripts can be used for local testing and for deploying Always On VPN connections using System Center Configuration Manager (SCCM). The ProfileXML files can be helpful for those administrators looking for real world configuration examples.

https://github.com/richardhicks/aovpn

SstpOffload

This repository includes a PowerShell script to enable TLS offload for Windows Server RRAS Secure Socket Tunneling Protocol (SSTP) VPN connections when the public SSL certificate can’t be installed on the RRAS server. TLS offload for SSTP can be enabled in scenarios where better security, performance, and scalability are desired.

https://github.com/richardhicks/sstpoffload

DirectAccess

This repository includes the PowerShell script Move-DaInboxAccountingDatabase which can be used to move the DirectAccess inbox accounting database files. The default location of the database files is on the C: drive, and many administrators have encountered disk space issues, especially in large scale deployments. This script will relocate the database files to the location of your choice.

https://github.com/richardhicks/directaccess

More to Come!

Be sure to check my GitHub site for more PowerShell script and sample files on a regular basis. Or better yet, give me a follow! I’ll be sure to post more as time goes on. In addition, I’ll be going through my older articles where I’ve provided PowerShell code samples and will include them in the repository too.

Standard Disclaimer

All the sample files and PowerShell scripts I’ve shared on GitHub are provided as-is. Although they’ve been thoroughly tested, I can’t be certain I’ve accommodated every deployment scenario. Please use caution when running these scripts on production machines.

Additional Information

Always On VPN Hands-On Training Classes 2019

Jeff Hicks’ Blog

Always On VPN IKEv2 and SSTP Fallback

Always On VPN IKEv2 and SSTP FallbackA while back I wrote about the various VPN protocols supported for Windows 10 Always On VPN. The two most common are Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP). The article covers in detail each protocol’s advantages and disadvantages. To summarize, IKEv2 provides the best security (when configured correctly!) and SSTP is firewall-friendly ensuring ubiquitous access. Ideally an Always On VPN connection will attempt to use the more secure IKEv2 first, then fallback to SSTP only when IKEv2 is unavailable. Unfortunately, Always On VPN connections do not work this way today.

IKEv2 and SSTP

IKEv2 and SSTP are not mutually exclusive. When using Windows Routing and Remote Access Service (RRAS) as the VPN server, both protocols can be configured and enabled for VPN clients. To allow VPN clients to automatically select a protocol, the NativeProtocolType element in ProfileXML can be set to Automatic.

Always On VPN IKEv2 and SSTP Fallback

IKEv2 with SSTP Fallback?

In theory, with the NativeProtocolType set to Automatic, the Windows 10 client would first attempt to establish an IKEv2 connection, then fall back to SSTP if IKEv2 is not available. In practice, this is not the case.

SSTP Preferred over IKEv2

In operation, setting the NativeProtocolType to Automatic results in the Windows 10 client attempting to establish a VPN connection using SSTP first! If the SSTP connection fails, only then will IKEv2 be used. The only scenario in which I can imagine SSTP failing and IKEv2 being successful would be if SSTP is not supported by the VPN server. Sadly, this scenario may result in failed connections due to a bug in the way ProfileXML settings are processed. Details here.

VPN Strategy

The initial VPN protocol selection behavior is dictated by the VpnStrategy setting of the Always On VPN connection in the rasphone.pbk file. This file can be found under C:\Users\[username]\AppData\Roaming\Microsoft\Network\Connections\Pbk. The documentation on the Microsoft website is terribly outdated and does not include the following important VpnStrategy settings pertinent to Windows 10 Always On VPN connections.

  • 5 = Only SSTP is attempted
  • 6 = SSTP is attempted first
  • 7 = Only IKEv2 is attempted
  • 8 = IKEv2 is attempted first
  • 14 = IKEv2 is attempted followed by SSTP

Always On VPN Default Behavior

For Always On VPN, when the NativeProtocolType is set to Automatic in ProfileXML, VpnStrategy is set to 6 by default, which means the connection will attempt to use SSTP first. If it fails, IKEv2 will be attempted.

Always On VPN IKEv2 and SSTP Fallback

If the NativeProtocolType in ProfileXML is set to IKEv2, VpnStrategy is set to 7 and only IKEv2 is used. A connection using SSTP is never attempted.

Workaround

Setting the VpnStrategy to 8 or 14 will force the client to attempt an IKEv2 connection first. However, this setting is dynamically updated by Windows and is subject to change. For example, if an IKEv2 connection fails and SSTP is successful, Windows will then set the VpnStrategy to 6 and all subsequent VPN connection attempts will use SSTP first. Because of this it will be necessary to update the VpnStrategy setting each time prior to establishing a VPN connection. This will require some clever scripting and perhaps automation using a scheduled task based on an event trigger. I will leave that custom configuration as an exercise for the reader. If you’ve developed something to address this challenge, please feel free to share in the comments below. 🙂

Additional Information

Always On VPN Protocol Recommendations for Windows Server RRAS

Always On VPN IKEv2 Security Configuration

Always On VPN Certificate Requirements for IKEv2

Always On VPN IKEv2 Load Balancing with KEMP LoadMaster Load Balancer

Troubleshooting Always On VPN Error Code 0x80092013

Troubleshooting Always On VPN Error Code 0x80092013Windows Server Routing and Remote Access Service (RRAS) is commonly used for Windows 10 Always On VPN deployments because it is easy to configure and manage and it includes Microsoft’s proprietary Secure Socket Tunneling Protocol (SSTP). SSTP is a Transport Layer Security (TLS) VPN protocol that is firewall-friendly and ubiquitously available. However, a common configuration mistake can lead to failed connections.

Error 0x80092013

A Windows 10 Always On VPN client may fail to establish a VPN connection to an RRAS VPN server when using SSTP. The VPN client will return the following error message.

“Can’t connect to Always On VPN. The revocation function was unable to check revocation because the revocation server was offline.”

Troubleshooting Always On VPN Error Code 0x80092013

The event log will also include RasClient event ID 20227 with the following error.

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

Troubleshooting Always On VPN Error Code 0x80092013

The Win32 error code –2146885613 converts to hexadecimal 0x80092013, which translates to CRYPT_E_REVOCATION_OFFLINE, indicating that the client was unable to successfully perform a check of the VPN server’s SSL certificate.

Revocation Checking

When the VPN client attempts to establish an SSTP connection to the Windows RRAS VPN, it will check the Certification Revocation List (CRL) using the information provided in the SSL certificate. If the CRL is unreachable for any reason, the client will not complete the connection

Common Cause of Error 0x80092013

Certificate revocation failures for Windows 10 Always On VPN SSTP connections commonly occur when the RRAS VPN server is configured with an SSL certificate issued by an internal certification authority (CA) and the CRL is not publicly available.

Resolving Error 0x80092013

Making the internal CA’s CRL available publicly will of course resolve this error. However, best practice recommendations for the SSTP SSL certificate call for the use of a certificate issued by a public CA. For detailed information about SSL certificate requirements and recommendations, please see Always On VPN SSL Certificate Requirements for SSTP.

Additional Information

Always On VPN SSL Certificate Requirements for SSTP

Always On VPN ECDSA SSL Certificate Request for SSTP

Always On VPN Protocol Recommendations for Windows RRAS

Always On VPN ECDSA SSL Certificate Request for SSTP

As I’ve discussed previously, it is strongly recommended that the TLS certificate used for SSTP be signed using the Elliptic Curve Digital Signature Algorithm (ECDSA). ECDSA provides better security and performance compared to RSA certificates for Windows 10 Always On VPN connections using SSTP. See my previous post Always On VPN SSL Certificate Requirements for SSTP for more information.

Certificate Signing Request

To generate a Certificate Signing Request (CSR) using ECDSA to send to a public Certification Authority (CA), open the local computer certificate store (certlm.msc) on any Windows server or client and follow the steps below.

  1. Expand Certificates – Local Computer.
  2. Right-click the Personal folder and choose All Tasks > Advanced Operations > Create Custom Request.
  3. Click Next.
  4. Select Proceed without enrollment policy.
  5. Click Next.
  6. From the Template drop-down list choose (No template) CNG key.
  7. Click Next.
  8. Click Details.Always On VPN ECDSA SSL Certificate Request for SSTP
  9. Click Properties.
  10. On the General tab enter a name in the Friendly name field.
  11. Click on the Subject tab.
    1. In the Subject name section, from the Type drop-down list choose Common name.
    2. In the Value field enter the VPN server’s public hostname and click Add.
    3. In the Alternative name section, from the Type drop-down list choose DNS.
    4. In the Value field enter the VPN server’s public hostname and click Add.Always On VPN ECDSA SSL Certificate Request for SSTP
  12. Click on the Extensions tab.
    1. Expand Extended Key Usage (application policies).
    2. Highlight Server Authentication.
    3. Click Add.Always On VPN ECDSA SSL Certificate Request for SSTP
  13. Click on the Private Key tab.
    1. Expand Cryptographic Service Provider.
    2. Uncheck RSA,Microsoft Software Key Storage Provider.
    3. Check ECDSA_P256,Microsoft Software Key Storage Provider.Always On VPN ECDSA SSL Certificate Request for SSTP
  14. Expand Key options.
    1. Select the option to Make private key exportable.Always On VPN ECDSA SSL Certificate Request for SSTP
  15. Click Ok.
  16. Click Next.
  17. Enter a name for the file in the File Name field.
  18. Click Finish.

Submit the Request

Once complete, submit the CSR for signing to your favorite public CA. Based on my experience, some CAs are easier to obtain ECDSA-signed certificates than other. Today, Digicert seems to be one of the better public CAs for obtaining EC TLS certificates.

Complete the Request

Once the CA has issued the certificate, import the certificate in to the local computer certificate store on the same client or server where the original CSR was created. The certificate can then be exported and imported on additional VPN servers, if required.

Additional Information

Always On VPN SSL Certificate Requirements for SSTP

Always On VPN Protocol Recommendations for RRAS

 

Always On VPN SSL Certificate Requirements for SSTP

Always On VPN Certificate Requirements for SSTPThe Windows Server 2016 Routing and Remote Access Service (RRAS) is commonly deployed as a VPN server for Windows 10 Always On VPN deployments. Using RRAS, Always On VPN administrators can take advantage of Microsoft’s proprietary Secure Socket Tunneling Protocol (SSTP) VPN protocol. SSTP is a Transport Layer Security (TLS) based VPN protocol that uses HTTPS over the standard TCP port 443 to encapsulate and encrypt communication between the Always On VPN client and the RRAS VPN server. SSTP is a firewall-friendly protocol that ensures ubiquitous remote network connectivity. Although IKEv2 is the protocol of choice when the highest level of security is required for VPN connections, SSTP can still provide very good security when implementation best practices are followed.

SSTP Certificate

Since SSTP uses HTTPS for transport, a common SSL certificate must be installed in the Local Computer/Personal/Certificates store on the RRAS VPN server. The certificate must include the Server Authentication Enhanced Key Usage (EKU) at a minimum. Often SSL certificates include both the Server Authentication and Client Authentication EKUs, but the Client Authentication EKU is not strictly required. The subject name on the certificate, or at least one of the Subject Alternative Name entries, must match the public hostname used by VPN clients to connect to the VPN server. Multi-SAN (sometimes referred to as UC certificates) and wildcard certificates are supported.

Always On VPN Certificate Requirements for SSTP

Certification Authority

It is recommended that the SSL certificate used for SSTP be issued by a public Certification Authority (CA). Public CAs typically have their Certificate Revocation Lists (CRLs) hosted on robust, highly available infrastructure. This reduces the chance of failed VPN connection attempts caused by the CRL being offline or unreachable.

Using an SSL certificate issued by an internal, private CA is supported if the CRL for the internal PKI is publicly available.

Key Type

RSA is the most common key type used for SSL certificates. However, Elliptic Curve Cryptography (ECC) keys offer better security and performance, so it is recommended that the SSTP SSL certificate be created using an ECC key instead.

Always On VPN Certificate Requirements for SSTP

To use an ECC key, be sure to specify the use of a Cryptographic Next Generation (CNG) key and select the ECDSA_P256 Microsoft Software Key Storage Provider (CSP) (or greater) when creating the Certificate Signing Request (CSR) for the SSTP SSL certificate.

Always On VPN Certificate Requirements for SSTP

Most public CAs will support certificate signing using ECC and Elliptic Curve Digital Signature Algorithm (ECDSA). If yours does not, find a better CA. 😉

Forward Secrecy

Forward secrecy (sometimes referred to as perfect forward secrecy, or PFS) ensures that session keys can’t be compromised even if the server’s private key is compromised. Using forward secrecy for SSTP is crucial to ensuring the highest levels of security for VPN connections.

To enforce the use of forward secrecy, the TLS configuration on the VPN server should be prioritized to prefer cipher suites with Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.

Authenticated Encryption

Authenticated encryption (AE) and authenticated encryption with associated data (AEAD) is a form of encryption that provides better data protection and integrity compared to older block or stream ciphers such as CBC or RC4.

To enforce the use of authenticated encryption, the TLS configuration on the VPN server should be prioritized to prefer cipher suites that support Galois/Counter Mode (GCM) block ciphers.

Important Note: In Windows Server 2016, GCM ciphers can be used with both RSA and ECC certificates. However, in Windows Server 2012 R2 GCM ciphers can only be used when an ECC certificate is used.

SSL Offload

Offloading SSL to a load balancer or application delivery controller (ADC) can be enabled to improve scalability and performance for SSTP VPN connections. I will cover SSL offload for SSTP in detail in a future post.

Summary

SSTP can provide good security for VPN connections when implementation and security best practices are followed. For optimum security, use an SSL certificate with an EC key and optimize the TLS configuration to use forward secrecy and authenticated cipher suites.

Additional Information

Always On VPN ECDSA SSL Certificate Request for SSTP

Always On VPN and Windows Server Routing and Remote Access Service (RRAS)

Always On VPN Protocol Recommendations for Windows Server RRAS

Always On VPN Certificate Requirements for IKEv2

3 Important Advantages of Always On VPN over DirectAccess

Microsoft SSTP Specification on MSDN

%d bloggers like this: