Always On VPN Error 13806

Troubleshooting Always On VPN Error 691 and 812 – Part 2

As a follow-up to my last post regarding Always On VPN error 13801, this post will cover a similar and related error administrators may encounter, the 13806 error. As mentioned previously, certificate configuration is crucial for Always On VPN deployments. I described some specific certificates requirements for IKEv2 in this earlier post. Following this guidance, administrators should have no issues with IKEv2 Always On VPN connections. However, it is always possible to encounter an error if any of these certificates are missing or misconfigured.

Error 13806

Much like the error 13801 described previously, 13806 is also common. When an Always On VPN connection using IKEv2 fails, the Windows Application event log will record an event ID 20227 from the RasClient source. The error message states the following:

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

IKE Failed To Find Valid Machine Certificate

Error 13806 translates to ERROR_IPSEC_IKE_NO_CERT, indicating IKE failed to find a valid machine certificate. The problem can be on the device, the VPN server, or an issue with the VPN server configuration.

Device Certificate

For the device tunnel, the most obvious cause of this error is a missing device authentication certificate on the client itself. Ensure the endpoint has a valid certificate issued by the organization’s internal PKI that includes Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2). The certificate must have a subject name matching the device’s FQDN. It must also be valid (not expired), trusted, and not revoked.

Certificate Chain

A 13806 error will occur if the device certificate installed on the client is not trusted or if the client does not trust the certificate installed on the VPN server. Ensure the client has all the necessary root and intermediate certification authority (CA) certificates installed in their respective certificate stores.

VPN Server Certificate

A 13806 error can also occur if the VPN server does not have a properly configured server certificate. Ensure the VPN server has a valid certificate issued by the organization’s internal PKI that includes both the Server Authentication (OID 1.3.6.1.5.5.7.3.1) and IP security IKE intermediate (OID 1.3.6.1.5.5.8.2.2) EKUs. The subject name must match the public fully qualified domain name (FQDN) used by VPN clients to connect to the VPN server (not the server’s NetBIOS name). Again, ensure the certificate is valid (not expired), trusted, not revoked, and all necessary root and intermediate CA certificates are installed in their respective certificate stores.

RRAS Configuration

Another cause of the 13806 error for the user tunnel is a misconfigured Routing and Remote Access Service (RRAS) VPN server. An error 13806 can happen if the administrator incorrectly defines a trusted root CA using Set-VpnAuthProtocol. Ensure that the root certificate thumbprint matches exactly the root CA server’s thumbprint used to issue certificates to VPN devices and the VPN server.

Get-VpnAuthProtocol

Root CA Certificate Thumbprint

Resolution

Ensure that devices and VPN servers have correctly configured certificates installed. If the root CA certificate is assigned incorrectly on the VPN server, follow the guidelines detailed here to update the configuration.

Additional Information

Microsoft Windows Always On VPN Error 13801

Microsoft Windows Always On VPN Certificate Requirements for IKEv2

Microsoft Windows Always On VPN IPsec Root Certificate Configuration Issue

Microsoft Windows Always On VPN IKEv2 Policy Mismatch Error

Microsoft Windows Always On VPN IKEv2 Security Configuration

Microsoft Windows Always On VPN IKEv2 Fragmentation

Microsoft Windows Always On VPN IKEv2 Load Balancing and NAT

Microsoft Windows Always On VPN IKEv2 Features and Limitations

Always On VPN Error 13801

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Certificate configuration is crucial for Always On VPN deployments. I described some specific certificates requirements for IKEv2 in this previous post. Following this guidance, administrators should have no issues with IKEv2 Always On VPN connections. However, it is always possible to encounter an error if any of these certificates are missing or misconfigured.

Error 13801

One of the most common errors related to IKEv2 and certificates is 13801. When an Always On VPN connection using IKEv2 fails, the Windows Application event log will record an event ID 20227 from the RasClient source. The error message states the following:

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

IKE Authentication Credentials are Unacceptable

Error 13801 translates to ERROR_IPSEC_IKE_AUTH_FAIL, indicating an authentication failure related to IPsec. The problem can be on the device, the VPN server, or an issue with the VPN server configuration.

Certificate Chain

A 13801 error will occur if the client does not trust the certificate installed on the VPN server. Ensure the client has all the necessary root and intermediate certification authority (CA) certificates installed in their respective certificate stores.

VPN Server Certificate

A 13801 error can also occur if the VPN server does not have a properly configured server certificate. Ensure the VPN server has a valid certificate issued by the organization’s internal PKI that includes both the Server Authentication (OID 1.3.6.1.5.5.7.3.1) and IP security IKE intermediate (OID 1.3.6.1.5.5.8.2.2) EKUs. The subject name must match the public fully qualified domain name (FQDN) used by VPN clients to connect to the VPN server (not the server’s NetBIOS name). Again, ensure the certificate is valid (not expired), trusted, not revoked, and all necessary root and intermediate CA certificates are installed in their respective certificate stores.

RRAS Configuration

Another cause of the 13801 error for the device tunnel is a misconfigured Routing and Remote Access Service (RRAS) VPN server. An error 13801 can happen if the administrator incorrectly defines a trusted root CA using Set-VpnAuthProtocol. Ensure that the root certificate thumbprint matches exactly the root CA server’s thumbprint used to issue certificates to VPN devices and the VPN server.

Get-VpnAuthProtocol

Root CA Certificate Thumbprint

Resolution

Ensure that devices and VPN servers have correctly configured certificates installed. If the root CA certificate is assigned incorrectly on the VPN server, follow the guidelines detailed here to update the configuration.

Additional Information

Microsoft Windows Always On VPN Error 13806 (Coming soon)

Microsoft Windows Always On VPN Certificate Requirements for IKEv2

Microsoft Windows Always On VPN IPsec Root Certificate Configuration Issue

Microsoft Windows Always On VPN IKEv2 Policy Mismatch Error

Microsoft Windows Always On VPN IKEv2 Security Configuration

Microsoft Windows Always On VPN IKEv2 Fragmentation

Microsoft Windows Always On VPN IKEv2 Load Balancing and NAT

Microsoft Windows Always On VPN IKEv2 Features and Limitations

Always On VPN and Intune Proactive Remediation

Always On VPN and Autopilot Hybrid Azure AD Join

When configuring and deploying Windows Always On VPN using Microsoft Endpoint Manager (MEM)/Intune, administrators may find that some settings are not exposed in the MEM UI. In some cases, deploying the configuration profile using custom XML is the workaround. However, many crucial Always On VPN settings are not exposed using either method. Here, administrators must resort to editing settings in the VPN configuration file on the client after provisioning the VPN profile.

Phonebook

A file called rasphone.pbk stores all Windows VPN settings on the endpoint. It includes name/value pairs that correspond to many settings administrators change manually in the GUI. Other settings can be changed using PowerShell. Depending on the connection type, the file can be found in one of two locations.

  • User Tunnel: $env:AppData\Microsoft\Network\Connections\Pbk\rasphone.pbk
  • Device Tunnel: $env:ProgramData\Microsoft\Network\Connections\Pbk\rasphone.pbk

Documentation for Windows VPN client phonebook entry settings can be found here.

Limitations

Unfortunately, editing the rasphone.pbk file isn’t always convenient. Making the changes is technically easy. Administrators can write a simple PowerShell script to update the text file as required. However, automating this at scale is challenging. Thankfully, Intune Proactive Remediations can help.

Proactive Remediations

With Intune Proactive Remediations, administrators can create and deploy script packages to monitor and optionally update specific configuration settings. The package includes two scripts, a detection script, and a remediation script. The detection script looks at the current value of a particular setting and reports on its compliance. The remediation script is triggered to update the setting if the value is incorrect.

Requirements

Intune Proactive Remediations has some specific licensing requirements. Administrators must also enroll devices into Endpoint analytics and provision a Windows Health Monitoring configuration profile. There are also limitations on the size and type of scripts that administrators can use. More information on prerequisites can be found here.

Script Packages

Administrators can create detection and remediation PowerShell scripts to update settings in rasphone.pbk, or optionally, they can download sample scripts from my GitHub repository here. This repository contains user and device tunnel detection and remediation scripts for many popular settings in rasphone.pbk. Examples include updating the VPN Strategy, changing VPN interface metrics, disabling class-based default routes, and many more.

Note: The scripts in my GitHub repository are examples only. While they can be used in production environments, they are basic and may not work as expected in all scenarios. For example, the scripts as written today assume only a single VPN profile provisioned. Unexpected results may occur if more than one VPN profile exists. Please use them at your own risk.

Deployment

In this example, we’ll deploy a Proactive Remediation to disable IKE mobility for user tunnel VPN connections. To configure an Intune Proactive Remediation, open the Microsoft Endpoint Manager portal (https://endpoint.microsoft.com/) and navigate to Reports > Endpoint analytics > Proactive remediations. After creating or downloading the detection and remediation scripts, perform the following steps to create and deploy a Proactive Remediation script package.

  1. Click Create script package.
  2. Enter a name for the package in the Name field.
  3. Enter a description for the package in the Description field (optional).
  4. Click Next.
  5. Click the blue folder icon next to the Detection script file field and upload the detection script.
  6. Click the blue folder icon next to the Remediation script file field and upload the associated remediation script.
  7. For user tunnel connections, click Yes next to Run this script using the logged-on credentials. For device tunnel connections, click No.
  8. Click Next.

Assign scope tags and group assignments as necessary, then click Create. Click Refresh to update the UI to display the newly created script package.

Caveats

Be advised that Proactive Remediation script packages run immediately after the first device sync and then every 24 hours after that. Timing issues could lead to delays in functionality. For example, if an Always On VPN profile is provisioned after a Proactive Remediation script runs, the changes made by the remediation script won’t be available until much later. Also, changes made while the VPN is active will not take effect until after restarting the connection.

Special Thanks

Special thanks to Tom Klaver at Inspark for turning me on to this feature. It has been an absolute lifesaver for sure!

Additional Information

Microsoft Intune Proactive Remediation Tutorial

Windows VPN Phonebook Entry Settings

Intune Proactive Remediation Script Samples on GitHub

Microsoft Windows Always On VPN Class-Based Default Route and Intune

Microsoft Windows Always On VPN Short Name Access Failure

Always On VPN Client Routes Missing

Choosing an Enterprise VPN

When configuring Always On VPN for Windows 10 and Windows 11 clients, administrators may encounter a scenario where an IPv4 route defined in Microsoft Endpoint Manager/Intune or custom XML is not reachable over an established Always On VPN connection. Further investigation indicates the route is added to the configuration on the endpoint but does not appear in the routing table when the connection is active.

Routing Configuration

When split tunneling is enabled, administrators must define routes to IP networks that are reachable over the Always On VPN connection. The method of defining these routes depends on the client configuration deployment method.

Endpoint Manager

Using Microsoft Endpoint Manager, administrators define IP routes in the Split Tunneling section of the configuration settings for the Always On VPN device configuration profile. Routes are defined by entering the destination prefix and prefix size. In this example, the 10.0.0.0/8 and 172.21.12.0/21 IPv4 networks are defined for routing over the Always On VPN tunnel.

Custom XML

Using custom XML deployed using Microsoft Endpoint Manager, System Center Configuration Manager (SCCM), or PowerShell, routes are defined in the XML file using the following syntax.

Client Configuration

Validate the routing configuration has been implemented on the endpoint successfully by running the following PowerShell command.

Get-VpnConnection -Name <Connection Name> | Select-Object -ExpandProperty Routes

As you can see here, the IPv4 routes 10.0.0.0/8 and 172.21.12.0/21 are included in the client’s Always On VPN configuration, as shown below.

Missing Route

However, after establishing an Always On VPN connection, the 172.21.12.0/21 network is not reachable. To continue troubleshooting, run the following PowerShell command to view the active routing table.

Get-NetRoute -AddressFamily IPv4

As you can see above, the only IPv4 route in the VPN configuration added to the routing table is the 10.0.0.0/8 network. The 172.21.12.0/21 IPv4 route is missing.

Network Prefix Definition

IPv4 routes missing from the Always On VPN client’s routing table result from incorrect network prefix definition. Specifically, the IPv4 route 172.21.12.0/21 used in the example here is not a valid network address. Rather, it is a host address in the 172.21.8.0/21 network, as shown below.

The Get-Subnet PowerShell cmdlet is part of the Subnet PowerShell module. To install this module, run the following PowerShell command.

Install-Module Subnet

Resolution

Using the example above, enabling access to the 172.21.12.0/21 subnet would require defining the IPv4 prefix in the routing configuration as 172.21.8.0/21. The moral of this story is always validate routing prefixes to ensure they are, in fact, network addresses and not host addresses.

Additional Information

Always On VPN Routing Configuration

Always On VPN Default Class-based Route and Microsoft Endpoint Manager/Intune

Always On VPN Book Available for Pre-Order

Great news! My new book, Implementing Always On VPN, is now available for pre-order on Amazon.com. This new book, scheduled for release in late 2021, is a comprehensive implementation guide for Windows 10 Always On VPN. Drawing on many years of experience deploying Always On VPN for organizations worldwide, it covers all aspects of an Always On VPN deployment, including planning and design, prerequisite gathering, infrastructure preparation, and client deployment.

In addition, it contains detailed, prescriptive guidance for advanced configuration options such as application and traffic filtering and proxy server configuration. Cloud deployments using Azure VPN gateway and Virtual WAN are covered, and it includes guidance for configuring Azure MFA and Conditional Access.

Also, the book includes thorough guidance for provisioning certificates using Microsoft Endpoint Manager/Intune using both PKCS and SCEP. It outlines options for high availability for VPN and authentication infrastructure and provides details for ongoing system maintenance and operational support.

Finally, the book has an entire chapter dedicated to troubleshooting and resolving common (and not so common!) issues encountered with Windows 10 Always On VPN.

Reserve your copy today. Pre-order Implementing Always On VPN now!

Chapter List

  1. Always On VPN Overview
  2. Plan an Always On VPN Deployment
  3. Prepare the Infrastructure
  4. Configure Windows Server for Always On VPN
  5. Provision Always On VPN clients
  6. Advanced Configuration
  7. Cloud Deployments
  8. Deploy Certificates with Intune
  9. Integrating Azure MFA
  10. High Availability
  11. Monitor and Report
  12. Troubleshooting

Always On VPN Authentication Failure with Azure Conditional Access

Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

Integrating Microsoft Azure Conditional Access with Windows 10 Always On VPN has several important benefits. The most important is that it allows administrators to improve their security posture by enforcing access polices that can be dynamically applied. For example, requiring multifactor authentication (MFA) for privileged users (e.g., administrators) or sign-ins that appear to be risky, the type of device they are connecting with, the health of the endpoint, and much more.

Authentication Failure

When configuring Always On VPN to support Azure Conditional Access, administrators may expeirence a failed authentication during preliminary testing. Specifically, an event ID 20227 from the RasClient source may be encountered with the following error message.

“The user <username> dialed a connection named <connection name> which has failed. The error code returned on failure is 812.”

Looking at the event logs on the Network Policy Server (NPS) server reveals an event ID 6273 from the Microsoft Windows security auditing source with Reason Code 258 and the following Reason.

“The revocation function was unable to check revocation for the certificate.”

Root Cause

When Azure Conditional Access is configured for Always On VPN, a short-lived certificate (1 hour lifetime) is provisioned by Azure. This certificate does not include revocation information because, by design, a short-lived certificate does not need to be revoked. However, by default NPS always checks revocation when client authentication certificates are used for authentication. Since the certificate does not include this information, certificate revocation fails.

Resolution

The way to resolve this issue is to disable certificate revocation checking for Protected Extensible Authentication Protocol (PEAP) authentication requests. To do this, open an elevated PowerShell window on the NPS server and run the following command.

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13\’ -Name IgnoreNoRevocationCheck -PropertyType DWORD -Value 1 -Force

Once complete, restart the NPS server for the changes to take effect.

Additional Information

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

Windows 10 Always On VPN Network Policy Server (NPS) Server 2019 Bug

Troubleshooting Always On VPN Error 853

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Using Windows Server Network Policy Server (NPS) servers is a common choice for authenticating Microsoft Windows 10 Always On VPN user tunnel connections. The NPS server is joined to the domain and configured with a Network Policy that defines the authentication scheme used by clients for authentication when establishing an Always On VPN connection. Protected Extensible Authentication Protocol (PEAP) using client authentication certificates recommended for most Always On VPN deployment scenarios.

Can’t Connect

Users establishing an Always On VPN user tunnel connection using PEAP and client authentication certificates may encounter a scenario in which a VPN connection attempt fails with the following error message.

“The remote access connection completed, but authentication failed because the certificate that authenticates the client to the server is not valid. Ensure that the certificate used for authentication is valid.”

Error 853

In addition, the Application event log records an event ID 20227 from the RasClient source that includes the following error message.

“The user <username> dialed a connection named <connection name> which has failed. The error code is 853.”

Missing NTAuth Certificate

Error code 853 is commonly caused by a missing issuing Certification Authority (CA) certificate in the NTAuth store on the NPS server. The NPS server must have the issuing CA certificate included in this store to perform authentication using client certificates. You can see the contents of the NTAuth certificate store by opening an elevated command window on the NPS server and running the following command.

certutil.exe -enterprise -viewstore NTAuth

Install Certificate

To install the issuing CA server’s certificate into the NTAuth store, copy the CA certificate to the NPS server, open an elevated command window, then run the following command.

certutil.exe -enterprise -addstore NTAuth <issuing CA certificate>

Once complete, view the store again, and you’ll see the issuing CA certificate listed in the NTAuth certificate store.

Additional Information

Troubleshooting Always On VPN Error Code 858

Troubleshooting Always On VPN Error Code 864

Always On VPN and Windows Server 2019 NPS Bug

Always On VPN Network Policy Server (NPS) Load Balancing

Microsoft Network Policy Server (NPS) Reason Codes

Always On VPN Device Tunnel with Azure VPN Gateway

Always On VPN Device Tunnel with Azure VPN GatewayAlways 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).

Always On VPN Device Tunnel with Azure VPN Gateway

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.

Always On VPN Device Tunnel with Azure VPN Gateway

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.

Always On VPN Device Tunnel with Azure VPN Gateway

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.

Always On VPN Device Tunnel with Azure VPN Gateway

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.

Always On VPN Device Tunnel with Azure VPN Gateway

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

Always On VPN Load Balancing with Kemp in Azure

Always On VPN Load Balancing with Kemp in AzureIn a recent post I discussed options for load balancing Windows Server Routing and Remote Access Service (RRAS) in Microsoft Azure for Always On VPN. There are many choices available to the administrator, however the best alternative is to use a dedicated Application Delivery Controller (ADC), or load balancer. The Kemp LoadMaster load balancer is an excellent choice here, as it is easy to configure and deploy. It is also very cost effective and offers flexible licensing plans, including a metered licensing option.

Deploy LoadMaster in Azure

To provision a Kemp LoadMaster load balancer in Microsoft Azure, open the Azure management console and perform the following steps.

1. Click Create Resource.
2. Enter LoadMaster in the search field.
3. Click on LoadMaster Load Balancer ADC Content Switch.

Always On VPN Load Balancing with Kemp in Azure

4. Choose an appropriate license model from the Select a software plan drop-down list.
5. Click Create.

Prepare Azure Instance

Follow the steps below to provision the Azure VM hosting the Kemp LoadMaster load balancer.

1. Choose an Azure subscription to and resource group to deploy the resources to.
2. Provide instance details such as virtual machine name, region, availability options, and image size.
3. Select an authentication type and upload the SSH private key or provide a username and password.
4. Click Next:Disks >.

Always On VPN Load Balancing with Kemp in Azure

5. Select an OS disk type.
6. Click Next: Networking >.

Always On VPN Load Balancing with Kemp in Azure

7. Select a virtual network and subnet for the load balancer.
8. Create or assign a public IP address.
9. Click Review + create.

Always On VPN Load Balancing with Kemp in Azure

LoadMaster Configuration

Once the virtual machine has been provisioned, open a web browser and navigate to the VM’s internal IP address on port 8443 to accept the licensing terms.

Always On VPN Load Balancing with Kemp in Azure

Next, log in with your Kemp ID and password to finish licensing the appliance.

Always On VPN Load Balancing with Kemp in Azure

Finally, log in to the appliance using the username ‘bal’ and the password provided when the virtual machine was configured.

Always On VPN Load Balancing with Kemp in Azure

Azure Network Security Group

A Network Security Group (NSG) is automatically configured and associated with the LoadMaster’s network interface when the appliance is created. Additional inbound security rules must be added to allow VPN client connectivity.

In the Azure management console open the properties for the LoadMaster NSG and follow the steps below to configure security rules to allow inbound VPN protocols.

SSTP

1. Click Inbound security rules.
2. Click Add.
3. Choose Any from the Source drop-down list.
4. Enter * in the Source port ranges field.
5. Select Any from the Destination drop-down list.
6. Enter 443 in the Destination port ranges field.
7. Select the TCP protocol.
8. Select the Allow action.
9. Enter a value in the Priority field.
10. Enter a name for the service in the Name field.
11. Click Add.

Always On VPN Load Balancing with Kemp in Azure

IKEv2

1. Click Inbound security rules.
2. Click Add.
3. Choose Any from the Source drop-down list.
4. Enter * in the Source port ranges field.
5. Select Any from the Destination drop-down list.
6. Enter 500 in the Destination port ranges field.
7. Select the UDP protocol.
8. Select the Allow action.
9. Enter a value in the Priority field.
10. Enter a name for the service in the Name field.
11. Click Add.
12. Repeat the steps below for UDP port 4500.

Always On VPN Load Balancing with Kemp in Azure

Load Balancing SSTP and IKEv2

Refer to the following posts for detailed, prescriptive guidance for configuring the Kemp LoadMaster load balancer for Always On VPN load balancing.

Always On VPN SSTP Load Balancing with Kemp LoadMaster

Always On VPN IKEv2 Load Balancing with the Kemp LoadMaster

Always On VPN Load Balancing Deployment Guide for the Kemp LoadMaster

Summary

Although Windows Server RRAS is not a formally supported workload in Azure, it is still a popular and effective solution for Always On VPN deployments. The Kemp LoadMaster load balancer can be deployed quickly and easily to provide redundancy and increase scalability for larger deployments.

Additional Information

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

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster Load Balancers

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

Deploying the Kemp LoadMaster Load Balancer in Microsoft Azure

Always On VPN Load Balancing for RRAS in Azure

Always On VPN Load Balancing for RRAS in AzurePreviously I wrote about Always On VPN options for Microsoft Azure deployments. In that post I indicated that running Windows Server with the Routing and Remote Access Service (RRAS) role for VPN was an option to be considered, even though it is not a formally supported workload. Despite the lack of support by Microsoft, deploying RRAS in Azure works well and is quite popular. In fact, I recently published some configuration guidance for RRAS in Azure.

Load Balancing Options for RRAS

Multiple RRAS servers can be deployed in Azure to provide failover/redundancy or to increase capacity. While Windows Network Load Balancing (NLB) can be used on-premises for RRAS load balancing, NLB is not supported and doesn’t work in Azure. With that, there are several options for load balancing RRAS in Azure. They include DNS round robin, Azure Traffic Manager, the native Azure load balancer, Azure Application Gateway, or a dedicated load balancing virtual appliance.

DNS Round Robin

The easiest way to provide load balancing for RRAS in Azure is to use round robin DNS. However, using this method has some serious limitations. Simple DNS round robin can lead to connection attempts to a server that is offline. In addition, this method doesn’t accurately balance the load and often results in uneven distribution of client connections.

Azure Traffic Manager

Using Azure Traffic Manager is another alternative for load balancing RRAS in Azure. In this scenario each VPN server will have its own public IP address and FQDN for which Azure Traffic Manager will intelligently distribute traffic. Details on configuring Azure Traffic Manager for Always On VPN can be found here.

Azure Load Balancer

The native Azure load balancer can be configured to provide load balancing for RRAS in Azure. However, it has some serious limitations. Consider the following.

  • Supports Secure Socket Tunneling Protocol (SSTP) only.
  • Basic health check functionality (port probe only).
  • Limited visibility.
  • Does not work with IKEv2.
  • Does not support TLS offload for SSTP.

More information about the Azure Load Balancer can be found here.

Azure Application Gateway

The Azure Application Gateway can be used for load balancing RRAS SSTP VPN connections where advanced capabilities such as enhanced health checks and TLS offload are required. More information about the Azure Application Gateway can be found here.

Load Balancing Appliance

Using a dedicated Application Delivery Controller (ADC), or load balancer is a very effective way to eliminate single points of failure for Always On VPN deployments hosted in Azure. ADCs provide many advanced features and capabilities to ensure full support for all RRAS VPN protocols. In addition, ADCs offer much better visibility and granular control over VPN connections. There are many solutions available as virtual appliances in the Azure marketplace that can be deployed to provide RRAS load balancing in Azure.

Summary

Deploying Windows Server RRAS in Azure for Always On VPN can be a cost-effective solution for many organizations. Although not a formally supported workload, I’ve deployed it numerous times and it works quite well. Consider using a dedicated ADC to increase scalability or provide failover and redundancy for RRAS in Azure whenever possible.

Additional Information

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN and RRAS in Microsoft Azure

Windows 10 Always On VPN with Microsoft Azure Gateway

%d bloggers like this: