Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Always On VPN SSTP Load Balancing with Citrix NetScaler ADCThe Internet Key Exchange version 2 (IKEv2) VPN protocol is the protocol of choice when the highest level of security is required for Always On VPN connections. It uses IPsec and features configurable security parameters that allow administrators to adjust policies to meet their specific security requirements. IKEv2 is not without some important limitations, but organizations may insist on the use of IKEv2 to provide the greatest protection possible for remote connected clients. Due to complexities of the IKEv2 transport, special configuration on the Citrix ADC is required when load balancing this workload.

Special Note: In December 2019 a serious security vulnerability was discovered on the Citrix ADC that gives an unauthenticated attacker the ability to arbitrarily execute code on the appliance. As of this writing a fix is not available (due end of January 2020) but a temporary workaround can be found here.

Load Balancing IKEv2

When an Always On VPN client establishes a connection using IKEv2, communication begins on UDP port 500, but switches to UDP port 4500 if Network Address Translation (NAT) is detected in the communication path between the client and the server. Because UDP is connectionless, custom configuration is required to ensure that VPN clients maintain connectivity to the same backend VPN server during this transition.

Initial Configuration

Load balancing IKEv2 using the Citrix ADC is similar to other workloads. Below are specific settings and parameters required to load balance IKEv2 using the Citrix ADC.

Note: This article is not a comprehensive configuration guide for the Citrix ADC. It assumes the administrator is familiar with basic load balancing concepts and has experience configuring the Citrix ADC.

Service Settings

The load balancing services for IKEv2 VPN will use UDP ports 500 and 4500. Create the service group and assign group members for UDP 500 as follows.

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Repeat the steps above to create the service group for UDP port 4500.

Virtual Server Settings

Two virtual servers are required, one for UDP port 500 and one for UDP port 4500. Ensure that the service group using UDP port 500 is bound to the virtual server using the same port.

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Repeat the steps above to create the virtual service for UDP port 4500.

Service Monitoring

Since IKEv2 uses the UDP protocol, the only option for service monitoring is to use PING, which is configured by default. Ensure that the firewall on the VPN server allows inbound ICMPv4 and ICMPv6 Echo Request. The default PING monitor on the Citrix ADC will ping the resource every 5 seconds. If a different interval is required, the administrator can edit the PING monitor and bind that to the service or service group as necessary.

Persistency Group

A Persistency Group on the Citrix ADC will be configured to ensure that IKEv2 VPN client requests from the same client are always routed to the same backend server. Follow the steps below to create a Persistency Group and assign it to both IKEv2 virtual servers created previously.

1. In the Citrix ADC management console expand Traffic Management > Load Balancing > Persistency Groups.
2. Click Add.
3. Enter a descriptive name for the Persistency Group.
4. Select SOURCEIP from the Persistence drop-down list.
5. Next to the Virtual Server Name section click the Add button.
6. Add both previously configured IKEv2 virtual servers for UDP 500 and 4500.
7. Click Create.

Always On VPN IKEv2 Load Balancing with Citrix NetScaler ADC

Additional Information

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

Windows 10 Always On VPN IKEv2 Features and Limitations

Windows 10 AlWAYS On VPN and IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Certificate Requirements for IKEv2

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 IKEv2 Load Balancing Issue with Kemp LoadMaster

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMasterA recent update to the Kemp LoadMaster load balancer may cause failed connections for Always On VPN connections using IKEv2. SSTP VPN connections are unaffected.

Load Balancing IKEv2

When using the Kemp LoadMaster load balancer to load balance IKEv2, custom configuration is required to ensure proper operation. Specifically, the virtual service must be configured to use “port following” to ensure both the initial request on UDP port 500 and the subsequent request on UDP port 4500 are sent to the same real server. This requires the virtual service to be configured to operate at layer 7. Detailed configuration guidance for load balancing IKEv2 on the Kemp LoadMaster load balancer can be found here.

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Issues with LMOS 7.2.48.0

A recent release of the Load Master Operating System (LMOS) v7.2.48.0 introduced a bug that affects UDP services configured to operate at layer 7, which includes IKEv2. This bug breaks Always On VPN connections using IKEv2, resulting in failed connections. When this occurs, the administrator may encounter an error 809 message for device tunnel or user tunnel.

Always On VPN IKEv2 Load Balancing Issue with Kemp LoadMaster

Update Available

Administrators who use the Kemp LoadMaster load balancer to load balance Always On VPN IKEv2 connections and have updated to LMOS 7.2.48.0 are encouraged to update to LMOS 7.2.48.1 immediately. This latest update includes a fix that resolves broken IKEv2 load balancing for Always On VPN. Once the LoadMaster has been updated to 7.2.48.1, Always On VPN connections using IKEv2 should complete successfully.

Additional Information

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

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

Windows 10 Always On VPN Load Balancing with Kemp LoadMaster in Azure

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

Always On VPN IKEv2 Policy Mismatch Error

Always On VPN IKEv2 Policy Mismatch ErrorThe Internet Key Exchange version 2 (IKEv2) VPN protocol is the protocol of choice for Windows 10 Always On VPN deployments where the highest levels of security and assurance are required. However, as I’ve written about in the past, often the default IKEv2 security settings are less than desirable. Before using IKEv2 VPN in a production environment the administrator will need to update these security settings accordingly.

Connection Failure

When configuring Windows Server Routing and Remote Access Service (RRAS) or a third-party VPN appliance to support IKEv2 using custom security policies, the administrator may encounter a scenario in which a connection cannot be established due to a policy mismatch error. When the connection attempt fails, an error will be recorded in the Windows Application event log from the RasClient source with Event ID 20227. 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 13868.”

Always On VPN IKEv2 Policy Mismatch Error

Error Code 13868

Error code 13868 translates to ERROR_IPSEC_IKE_POLICY_MATCH. Essentially this error indicates that the IKEv2 security policy on the client did not match the configuration on the server.

Server Configuration

To view the current IKEv2 IPsec policy configuration, open an elevated PowerShell command window and run the following command.

Get-VpnServerIPsecConfiguration

Always On VPN IKEv2 Policy Mismatch Error

Client Configuration

To ensure interoperability, the VPN client must be configured to use the same IKEv2 security policy as defined on the sever. To view a VPN client’s currently configured IKEv2 security policy, open an elevated PowerShell command window and run the following command.

Get-VpnConnection -Name [connection name] | Select-Object -ExpandProperty IPsecCustomPolicy

Always On VPN IKEv2 Policy Mismatch Error

Note: If this PowerShell command returns no output, the VPN connection is not using a custom IKEv2 IPsec security policy.

Updating Settings

Guidance for configuring IKEv2 security policies on Windows Server RRAS and Windows 10 can be found here.

Summary

IKEv2 policy mismatch errors can be resolved easily by ensuring both the VPN server and client are configured to use the same IPsec security policies. Use the PowerShell commands in the above referenced above to validate settings and make changes when necessary.

Additional Information

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN IKEv2 Features and Limitations

Show-VpnConnectionIPsecConfiguration PowerShell script on Github

Set-IKEv2SecurityBaseline PowerShell script on Github

Always On VPN with Azure Gateway

Always On VPN with Azure GatewayRecently I wrote about VPN server deployment options for Windows 10 Always On VPN in Azure. In that post I indicated the native Azure VPN gateway could be used to support Always On VPN connections using Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP). In this post I’ll outline the requirements and configuration steps for implementing this solution.

Requirements

To support Always On VPN, point-to-site VPN connections must be enabled on the Azure VPN gateway. Not all Azure VPN gateways are alike, and point-to-site connections are not supported in all scenarios. For Always On VPN, the Azure VPN gateway must meet the following requirements.

VPN SKU

The Azure VPN gateway SKU must be VpnGw1, VpnGw2, VpnGw3, VpnGw1AZ, VpnGw2AZ, or VpnGw3AZ. The Basic SKU is not supported.

VPN Type

The VPN type must be route-based. Policy-based VPN gateways are not supported for point-to-site VPN connections.

Limitations

Using the Azure VPN gateway for Always On VPN may not be ideal in all scenarios. The following limitations should be considered thoroughly before choosing the Azure VPN gateway for Always On VPN.

Device Tunnel

RADIUS/EAP authentication for user tunnel connections is not supported if the Azure VPN gateway is configured to support device tunnel with machine certificate authentication.

Maximum Connections

A maximum of 250, 500, and 1000 concurrent IKEv2 connections are supported when using the VpnGw1/AZ, VpnGw2/AZ, and VpnGw3/AZ SKUs, respectively (x2 for active/active gateway deployments). In addition, a maximum of 128 concurrent SSTP connections are supported for all VPN gateway SKUs (x2 for active/active gateway deployments).

Always On VPN with Azure Gateway

Reference: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpngateways#gwsku

RADIUS Requirements

To support Always On VPN connections, the Azure VPN gateway must be configured to authenticate to a RADIUS server. The RADIUS server must be reachable from the VPN gateway subnet. The RADIUS server can be hosted in Azure or on-premises. Before proceeding, ensure that any network routes, firewall rules, and site-to-site VPN tunnel configuration is in place to allow this communication.

RADIUS Configuration

Guidance for configuring Windows Server NPS for Always On VPN can be found here. The only difference when configuring NPS for use with Azure VPN gateway is the RADIUS client configuration.

Open the NPS management console (nps.msc) and follow the steps below to configure Windows Server NPS to support Always On VPN client connections from the Azure VPN gateway.

1. Expand RADIUS Clients and Servers.
2. Right-click RADIUS Clients and choose New.
3. Enter a descriptive name in the Friendly name field.
4. Enter the Azure VPN gateway subnet using CIDR notation in the Address (IP or DNS) field. The gateway subnet can be found by viewing the properties of the Azure VPN gateway in the Azure portal.
5. Enter the shared secret to be used for RADIUS communication in the Shared secret field.

Always On VPN with Azure Gateway

Azure VPN Gateway Configuration

To begin, provision a Virtual Network Gateway in Azure that meets the requirements outlined above. Guidance for implementing an Azure VPN gateway can be found here. Once complete, follow the steps below to enable support for Always On VPN client connections.

Enable Point-to-Site

Perform the following steps to enable point-to-site VPN connectivity.

1. In the navigation pane of the Azure VPN gateway settings click Point-to-site configuration.
2. Click Configure Now 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 any IP address ranges defined in the Azure virtual network.
3. From the Tunnel type drop-down list select IKEv2 and SSTP (SSL).
4. In the RADIUS authentication field enter the IPv4 address of the RADIUS server. At the time of this writing only a single IPv4 address is supported. If RADIUS redundancy is required, consider creating a load balanced NPS cluster.
5. In the Server secret field enter the RADIUS shared secret.
6. Click Save to save the configuration.

Always On VPN with Azure Gateway

VPN Client Configuration

Perform the following steps to configure a Windows 10 VPN client to connect to the Azure VPN gateway.

Download VPN Configuration

1. Click Point-to-site configuration.
2. Click Download VPN client.
3. Select EAPMSCHAv2 (yes, that’s correct even if EAP-TLS will be used!)
4. Click Download.
5. Open the downloaded zip file and extract the VpnSettings.XML file from the Generic folder.
6. 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.

Always On VPN with Azure Gateway

Create a Test VPN Connection

On a Windows 10 device create a test VPN profile using the VPN server address copied previously. Configure EAP settings to match those configured on the NPS server and test connectivity.

Create an Always On VPN Connection

Once the VPN has been validated using the test profile created previously, the VPN server and EAP configuration from the test profile can be used to create the Always On VPN profile for publishing using Intune, SCCM, or PowerShell.

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 DH key (1024 bit) is used in phase 1 negotiation.

Always On VPN with Azure 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

Microsoft Azure VPN Gateway Overview

About Microsoft Azure Point-to-Site VPN

Windows 10 Always On VPN IKEv2 Security Configuration

 

 

 

Always On VPN DNS Registration Update Available

Always On VPN DNS Registration Update AvailableWhen configuring Always On VPN, administrators have the option to enable DNS registration for VPN clients. When this option is set, VPN clients will register the IP address assigned to their VPN interface in the internal DNS. This allows client devices to be managed using their hostname from the internal network whenever they are connected remotely.

DNS Registration

DNS registration is enabled in one of two ways, depending on how Always On VPN client devices are managed.

Intune

When using the native Microsoft Intune UI to manage Always On VPN profiles, DNS registration can be configured by selecting Enabled next to Register IP addresses with internal DNS in the Base VPN settings section.

Always On VPN DNS Registration Update Available

ProfileXML

When using custom ProfileXML with PowerShell, SCCM, or Intune, the administrator will define the RegisterDNS element to enable DNS registration.

Always On VPN DNS Registration Update Available

Known Issues

Some users have reported unexpected behavior when DNS registration is enabled. Specifically, under some circumstances the VPN client will register the IP address of the VPN network interface along with the IP address of its public network interface (Wi-Fi, Ethernet, etc.). However, the VPN client can only be managed using the VPN interface. If the VPN client’s hostname resolves to its public IP address, manage out will fail.

This appears to happen only when Name Resolution Policy Table (NRPT) rules are defined in Intune DNS settings, or if the DomainNameInformation element is defined in ProfileXML.

Always On VPN DNS Registration Update AvailableAlways On VPN DNS Registration Update Available

Resolution

Microsoft recently released fixes for this DNS registration issue for Windows 10. The fix for this issue is included in the following updates.

Windows 10 1803 – KB4507466
Windows 10 1809 – KB4505658
Windows 10 1903 – KB4505903

Additional Configuration

After installing the update, the following registry entry must be defined on each VPN client.

HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\DisableNRPTForAdapterRegistration DWORD = 1

To enable this setting, open an elevated PowerShell window and run the following command.

New-ItemProperty -Path ‘HKLM:SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\’ -Name DisableNRPTForAdapterRegistration -PropertyType DWORD -Value 1 -Force

Once complete, restart the client device for the changes to take effect. After validation testing is complete, the registry entry can be deployed to Always On VPN clients using Active Directory group policy preferences or Intune.

Additional Information

Deploying Windows 10 Always On VPN with Intune using Custom ProfileXML

Windows 10 Always On VPN Updates to Improve Connection Reliability

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Windows 10 Always On VPN Hands-On Training Classes

Deploying Always On VPN with Intune using Custom ProfileXML

Deploying Always On VPN with Intune using Custom ProfileXMLWhen deploying Windows 10 Always On VPN using Microsoft Intune, administrators have two choices for configuring VPN profiles. They can use the native Intune user interface (UI) or create and upload a custom ProfileXML. The method chosen will depend on which features and settings are required.

Microsoft Intune

Intune has an intuitive user interface (UI) that can be used to configure and deploy Always On VPN profiles to Windows 10 clients. Guidance for using the UI to deploy Windows 10 Always On VPN with Microsoft Intune can be found here. However, Intune does not expose all Always On VPN settings to the administrator, which can be problematic.

Missing from Intune

At the time of this writing, the following Always On VPN settings cannot be configured natively using the Intune UI.

To implement any of the above features or settings the administrator must create and upload a custom ProfileXML.

ProfileXML

ProfileXML is a node within the VPNv2 Configuration Service Provider (CSP). When configuring Always On VPN using the Intune UI, each setting is configured individually. By contrast, the ProfileXML node includes all Always On VPN settings in a single configuration file. It can be deployed using Intune or PowerShell. Sample ProfileXML files for both user and device tunnels can be downloaded from my GitHub repository.

ProfileXML and Intune

I’ve already documented how to deploy an Always On VPN device tunnel configuration using Intune, so this post will focus on deploying the user tunnel using ProfileXML.

Once ProfileXML has been configured, open the Intune management console and follow the steps below to deploy it using Intune.

Create Profile

1. In the navigation pane click Device Configuration.
2. Click Profiles.
3. Click Create Profile.
4. Enter a descriptive name for the new VPN profile.
5. Select Windows 10 and later from the Platform drop-down list.
6. Select Custom from the Profile type drop-down list.

Custom OMA-URI Settings

1. In the Custom OMA-URI Settings blade click Add.
2. Enter a descriptive name in the Name field (this name will appear in the Windows UI on the client).
3. Enter ./User/Vendor/MSFT/VPNv2/Always%20On%20VPN/ProfileXML in the OMA-URI field. I’ve used Always On VPN as an example here, but you can use any text you like. If it includes spaces they must be escaped using %20, as shown here. Also, don’t forget to include the leading “.“.
4. Select String (XML file) from the Data type drop-down list.
5. Click the folder next to the Select a file field and select your ProfileXML file.
6. Click Ok.

Deploying Always On VPN with Intune using Custom ProfileXML

Important Note: The File contents window must show the contents of your ProfileXML. If the contents are unreadable the XML file contains encoding that will not work. If this happens, copy the contents of your ProfileXML to another new text file and upload again.

Assign Profile

Follow the steps below to assign the Always On VPN profile to the appropriate user group.

1. Click Assignments.
2. Click Select groups to include.
3. Select the group that includes the target users.
4. Click Select.
5. Click Save.

Deploying Always On VPN with Intune using Custom ProfileXML

Demonstration Video

A demonstration video with guidance for deploying a Windows 10 Always On VPN user tunnel using the native Microsoft Intune UI as well as custom ProfileXML can be found here. The custom ProfileXML guidance starts at 7:52.

Additional Information

Deploying Windows 10 Always On VPN with Microsoft Intune

Deploying Windows 10 Always On VPN Device Tunnel using PowerShell

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN LockDown Mode

Windows 10 Always On VPN Scripts and Sample ProfileXML Files on GitHub

Always On VPN Device Tunnel and Certificate Revocation

Always On VPN Device Tunnel and Certificate RevocationRecently 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

Always On VPN Device Tunnel and Certificate Revocation

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

 

 

Denying Access to Always On VPN Users or Computers

Denying Access to Always On VPN Users or ComputersOnce Windows 10 Always On VPN has been deployed in production, it may be necessary at some point for administrators to deny access to individual users or computers. Commonly this occurs when an employee is terminated or leaves the company, or if a device is lost, stolen, or otherwise compromised. Typically, this means that user accounts and computer accounts in Active Directory are disabled, and any issued certificates are revoked. However, additional steps may be required to disconnect current VPN sessions or prevent future remote connections.

Certificate Revocation

When certificates are used for authentication, for example when a device tunnel is deployed, or a user tunnel is configured to use Extensible Authentication Protocol (EAP) with user certificate authentication, immediately revoking issued user and device certificates and publishing a new Certificate Revocation List (CRL) is recommended. However, this will not instantly prevent VPN access because revocation information is cached on the VPN and NPS servers, as well as any online responders. The process of flushing certificate revocation caches is challenging and time consuming as well.

Blocking Users

To immediately prevent users from accessing the VPN, a security group must be created in Active Directory that contains users that will be denied access. In addition, a Network Policy must be created on the Network Policy Server (NPS) that denies access to users belong to this security group.

NPS Configuration

Once the security group has been created, open the NPS management console (nps.msc) and perform the following steps.

  1. Expand Policies.
  2. Right-click Network Policies and choose New.
  3. Enter a descriptive name for the policy in the Policy name field.
  4. Select Remote Access Server (VPN-Dial up) from the Type of network access server drop-down list.
  5. Click Next.
  6. Click Add.
    1. Select User Groups.
    2. Click Add.
    3. Click Add Groups.
    4. Select the security group create for denied users.
    5. Click Ok twice.
  7. Click Next.
  8. Select Access denied.
  9. Click Next four times and click Finish.

Denying Access to Always On VPN Users or Computers

Denying Access to Always On VPN Users or Computers

Once complete, move the deny access policy so that it is before the policy that allows VPN access.

Denying Access to Always On VPN Users or Computers

Device Tunnel Considerations

Since device tunnel connections don’t use the NPS for authentication, blocking devices from establishing Always On VPN connections requires a different technique. Once again, revoking the computer certificate and publishing a new CRL is recommended, but isn’t immediately effective. To address this challenge, it is recommended that the computer certificate issued to the client be retrieved from the issuing CA and placed in the local computer’s Untrusted Certificates store on each VPN server, as shown here.

Note: The certificate must be imported on each VPN server in the organization.

Terminating Connections

Once the guidance above is put in to place, any user or device that is denied access will be unable to connect to the VPN. However, if a user or device is currently connected when these changes are implemented, additional steps must be taken to proactively terminate their existing session. When using Windows Server Routing and Remote Access Service (RRAS) as the VPN server, uUser sessions can be proactively terminated using RRAS management console or PowerShell.

GUI

To terminate an established Always On VPN connection, open the RRAS management console (rrasmgmt.msc), highlight Remote Access Clients, then right-click the client connection and choose Disconnect. Repeat the process for any additional connections established by the user or device.

Denying Access to Always On VPN Users or Computers

PowerShell

Alternatively, Always On VPN connections can also be terminated programmatically using PowerShell. To identify currently connected users on a VPN server, open an elevated PowerShell command window and run the following command.

Get-RemoteAccessConnectionStatistics | Format-Table -AutoSize

Next, to disconnect a user tunnel, identify the User Principal Name (UPN) of the user to disconnect and include it in the following PowerShell command.

Disconnect-VpnUser -UserName “user@corp.example.net”

To disconnect a device tunnel, identify the Fully-Qualified Domain Name (FQDN) of the device to disconnect and include it in the following PowerShell command.

Disconnect-VpnUser -UserName “client1.corp.example.net”

Additional Information

Windows 10 Always On VPN Hands-On Training

Always On VPN LockDown Mode

Always On VPN LockDown ModeWhen an Always On VPN connection is provisioned to a Windows 10 client, there’s nothing to prevent a user from disconnecting or even deleting the connection. Some administrators have expressed concern about this, fearful that users may disable the VPN to improve performance or circumvent access controls when force tunneling is enabled. Also, administrators may wish to prevent users from accidentally or purposefully making changes to the configuration, or even deleting the connection entirely.

LockDown Mode

To address these concerns, Microsoft included a feature called LockDown mode for Always On VPN. Once enabled, the following conditions apply.

  • The LockDown VPN connection is always on.
  • The LockDown VPN connection cannot be disabled.
  • The user can’t make changes to or delete the LockDown connection.
  • No other VPN connections can exist on the client.
  • Force tunneling is enabled by default (split tunneling in LockDown mode is not supported).

Challenges with LockDown Mode

Always On VPN LockDown mode brings with it some unique challenges, however. Consider the following.

Limited Protocol Support

LockDown mode only supports IKEv2 and the native (built-in) VPN client. Third-party plug-in provider clients are not supported. IKEv2 is an excellent VPN protocol in terms of security, but operationally speaking it has some serious drawbacks.

Force Tunneling Only

LockDown mode uses force tunneling exclusively. All network traffic must go over the VPN connection. However, if the VPN connection is not available, the client will be unable to access any network resources at all, local or remote.

Captive Portal Issues

LockDown mode prevents clients from connecting to network resources from a network with a captive portal.

On-premises Connectivity

In LockDown mode all network traffic must flow over the VPN tunnel even if the client is on the internal network. This also means that if the VPN server is not reachable internally (unable to resolve public hostname, protocols/ports blocked by internal firewall, unable to route to VPN server, etc.) the client will not be able to access any internal or external network resources at all.

Deleting a LockDown VPN Connection

Deleting a LockDown VPN connection is also challenging. Administrators will find that trying to delete it using the UI or PowerShell often fails. To delete a LockDown Always On VPN connection, use psexec.exe to open an elevated PowerShell command window running in the system context using the following command.

.\psexec.exe -i -s C:\windows\system32\WindowsPowerShell\v1.0\powershell.exe

In the new elevated PowerShell window run the following commands to delete the LockDown VPN connection.

$ConnectionName = ‘[LockDown VPN connection name]’
$ConnectionNameEscaped = $ConnectionName -replace ‘ ‘, ‘%20’
$CimInstance = Get-CimInstance -Namespace ‘root\cimv2\mdm\dmmap’ -ClassName ‘MDM_VPNv2_01′ -Filter “ParentID=’./Vendor/MSFT/VPNv2′ and InstanceID=’$ConnectionNameEscaped'”
Remove-CimInstance -CimInstance $CimInstance

Optionally, download and run Remove-LockDownVPN.ps1 here.

Summary

While Always On VPN LockDown mode might seem like a good idea initially, its implementation is heavy-handed and practically speaking ends up causing more problems than it solves. For administrators that plan to enable this feature, carefully consider the drawbacks and limitations outlined above and their impact on supportability and the user experience.

Additional Information

Windows Always On VPN Device Tunnel Config using Microsoft Intune

Windows 10 Always On VPN Security Configuration 

Windows 10 Always On VPN Hands-On Training

 

%d bloggers like this: