CORRECTION: This webinar will take place 14:00 BST on Thursday, 25 October.
For many years, DirectAccess has been the gold standard for enterprise remote access. Its seamless and transparent operation improves productivity for mobile workers, and since it is always on, administrators enjoy improved visibility and management for their field-based assets.
As incredible as DirectAccess is, it is not without its limitations. For example, DirectAccess works only with Windows Enterprise edition clients that are joined to the domain. Professional Edition and non-domain joined machines are not supported. It also lacks many of the security features enterprise organizations require, such as device health checks and granular network access. In addition, DirectAccess communication is complex, with many different layers of encapsulation, authentication, and encryption. High protocol overhead can lead to poor performance over high latency or low bandwidth connections.
NetMotion Mobility is a secure remote access solution that is an excellent alternative to DirectAccess. It provides the same seamless, transparent, always on remote connectivity that DirectAccess provides, while at the same time offering much more in terms of features and capabilities. It supports a much broader range of clients, includes native Network Access Control (NAC) and application filtering, and offers enhanced performance.
To learn more about NetMotion Mobility, join me on Thursday, 25 October at 14:00 BST for a free live webinar with NetMotion. I’ll provide an overview of NetMotion Mobility and how it compares with DirectAccess. I’ll also demonstrate how it can help overcome some of the inherent limitations of DirectAccess too. Register today!
Internet Key Exchange version 2 (IKEv2) is an IPsec-based VPN protocol with configurable security parameters that allows administrators to ensure the highest level of security for Windows 10 Always On VPN clients. It is the protocol of choice for deployments that require the best possible protection for communication between remote clients and the VPN server. IKEv2 has some unique requirements when it comes to load balancing, however. Because it uses UDP on multiple ports, configuring the load balancer requires some additional steps for proper operation. This article demonstrates how to enable IKEv2 load balancing using the Kemp LoadMaster load balancer.
IKEv2 and NAT
IKEv2 VPN security associations (SAs) begin with a connection to the VPN server that uses UDP port 500. During this initial exchange, if it is determined that the client, server, or both are behind a device performing Network Address Translation (NAT), the connection switches to UDP port 4500 and the connection establishment process continues.
IKEv2 Load Balancing Challenges
Since UDP is connectionless, there’s no guarantee that when the conversation switches from UDP 500 to UDP 4500 that the load balancer will forward the request to the same VPN server on the back end. If the load balancer forwards the UDP 500 session from a VPN client to one real server, then forwards the UDP 4500 session to a different VPN server, the connection will fail. The load balancer must be configured to ensure that both UDP 500 and 4500 from the same VPN client are always forwarded to the same real server to ensure proper operation.
Port Following
To meet this unique requirement for IKEv2 load balancing, it is necessary to use a feature on the KEMP LoadMaster load balancer called “port following”. Enabling this feature will ensure that a VPN client using IKEv2 will always have their UDP 500 and 4500 sessions forwarded to the same real server.
Load Balancing IKEv2
Open the web-based management console and perform the following steps to enable load balancing of IKEv2 traffic on the KEMP LoadMaster load balancer.
Create the Virtual Server
Expand Virtual Services.
Click Add New.
Enter the IP address to be used by the virtual server in the Virtual Address field.
Enter 500 in the Port field.
Select UDP from the Protocol drop-down list.
Click Add this Virtual Service.
Add Real Servers
Expand Real Servers.
Click Add New.
Enter the IP address of the VPN server in the Real Server Address field.
Click Add This Real Server.
Repeat the steps above for each VPN server in the cluster.
Repeat all the steps above to create another virtual server using UDP port 4500.
Enable Layer 7 Operation
Click View/Modify Services below Virtual Services in the navigation tree.
Select the first virtual server and click Modify.
Expand Standard Options.
Uncheck Force L4.
Check Transparency (additional configuration may be required – details here).
Select Source IP Address from the Persistence Options drop-down list.
Choose an appropriate value from the Timeout drop-down list.
Choose an appropriate setting from the Scheduling Method drop-down list.
Click Back.
Repeat these steps on the second virtual server.
Enable Port Following
Click View/Modify Services below Virtual Services in the navigation tree.
Select the first virtual server and click Modify.
Expand Advanced Properties.
Select the virtual server using UDP 500 from the Port Following drop-down list.
Click Back.
Repeat these steps on the second virtual server.
Demonstration Video
The following video demonstrates how to enable IKEv2 load balancing for Windows 10 Always On VPN using the KEMP LoadMaster Load Balancer.
Summary
With the KEMP LoadMaster load balancer configured to use port following, Windows 10 Always On VPN clients using IKEv2 will be assured that their connections will always be delivered to the same back end VPN server, resulting in reliable load balancing for IKEv2 connections.
Windows 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.”
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.”
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.