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 Options for Azure Deployments

Always On VPN Options for Azure DeploymentsOrganizations everywhere are rapidly adopting Microsoft Azure public cloud infrastructure to extend or replace their existing datacenter. As traditional on-premises workloads are migrated to the cloud, customers are looking for options to host VPN services there as well.

Windows Server

Windows Server with the Routing and Remote Access Service (RRAS) installed is a popular choice for on-premises Always On VPN deployments. Intuitively it would make sense to deploy Windows Server and RRAS in Azure as well. However, at the time of this writing, RRAS is not a supported workload on Windows Server in Azure.

Always On VPN Options for Azure Deployments

Reference: https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines/

Although explicitly unsupported, it is possible to deploy Windows Server and RRAS in Azure for Always On VPN. In my experience it works well and can be an option for organizations willing to forgo formal support by Microsoft.

Azure Gateway

Options for supporting Always On VPN connections using native Azure VPN infrastructure depend on the type of VPN gateway chosen.

VPN Gateway

The Azure VPN Gateway can be configured to support client-based (point-to-site) VPN. With some additional configuration it can be used to support Windows 10 Always On VPN deployments. Azure VPN gateway supports both IKEv2 and SSTP VPN protocols for client connections. The Azure VPN gateway has some limitations though. Consider the following:

  • A route-based VPN gateway is required
  • A maximum of 1000 concurrent IKEv2 connections are supported when using the VpnGw3 or VpnGw3AZ SKUs (2000 supported in active/active mode)
  • A maximum of 128 concurrent SSTP connections are supported on all gateway SKUs (256 supported in active/active mode)

Virtual WAN

Azure Virtual WAN is the future of remote connectivity for Azure. It includes support for client-based VPN (currently in public preview at the time of this writing), but only supports IKEv2 and OpenVPN VPN protocols for client connections. SSTP is not supported at all. Further, OpenVPN is not supported for Windows 10 Always On VPN, leaving IKEv2 as the only option, which poses some potential operational challenges. Virtual WAN offer much better scalability though, supporting up to 10,000 concurrent client-based VPN connections.

Virtual Appliance

The most supportable option for hosting VPN services in Azure for Windows 10 Always On VPN is to deploy a third-party Network Virtual Appliance (NVA). They are available from a variety of vendors including Cisco, Check Point, Palo Alto Networks, Fortinet, and many others. To support Windows 10 Always On VPN, the NVA vendor must either support IKEv2 for client-based VPN connections or have a Universal Windows Platform (UWP) VPN plug-in client available from the Microsoft store. Click here to learn more about Always On VPN and third-party VPN devices.

Note: Be careful when choosing an NVA as some vendors support IKEv2 only for site-to-site VPN, but not client-based VPN!

Hybrid Deployments

For organizations with hybrid cloud deployments (infrastructure hosted on-premises and in Azure), there are several options for choosing the best location to deploy VPN services. In general, it is recommended that client VPN connections be established nearest the resources accessed by remote clients. However, having VPN servers hosted both on-premises and in Azure is fully supported. In this scenario Azure Traffic Manager can be configured to intelligently route VPN connections for remote clients.

NetMotion Mobility

The NetMotion Mobility purpose-built enterprise VPN is a popular replacement for Microsoft DirectAccess. It is also an excellent alternative for enterprise organizations considering a migration to Always On VPN. It is a software-based solution that can be deployed on Windows Server and is fully supported running in Microsoft Azure. It offers many advanced features and capabilities not included in other remote access solutions.

Summary

Administrators have many options for deploying VPN servers in Azure to support Windows 10 Always On VPN. Windows Server and RRAS is the simplest and most cost-effective option, but it is not formally supported by Microsoft. Azure VPN gateway is an interesting alternative but lacks enough capacity for larger deployments. Azure Virtual WAN is another option but has limited protocol support. Deploying an NVA is a good choice, and NetMotion Mobility is an excellent alternative to both DirectAccess and Always On VPN that is software-based and fully supported in Azure.

Additional Information

Windows 10 Always On VPN and Third-Party VPN Devices

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

Windows 10 Always On VPN IKEv2 Features and Limitations

Windows 10 Always On VPN Multisite with Azure Traffic Manager

Comparing DirectAccess and NetMotion Mobility

Deploying NetMotion Mobility in Microsoft Azure

 

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).

Update for Windows Server

Microsoft recently made a fix for this issue available for Windows Server 2016. It is included in the June 18, 2019 update KB4503294 (build 14393.3053). A fix for Windows Server 2019 is forthcoming. Windows Server 2012 R2 will not be updated. It is recommended that you upgrade to a later version of the Windows Server operating system to  address this issue.

Note: This fix is now available for Windows Server 1903 (semi-annual channel). It is included in the June 27, 2019 update KB4501375 (build 18362.207).

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 IKEv2 Features and Limitations

Always On VPN IKEv2 Features and LimitationsThe Internet Key Exchange version 2 (IKEv2) VPN protocol is a popular choice for Windows 10 Always On VPN deployments. IKEv2 is a standards-based IPsec VPN protocol with customizable security parameters that allows administrators to provide the highest level of protection for remote clients. In addition, it provides important interoperability with a variety of VPN devices, including Microsoft Windows Server Routing and Remote Access Service (RRAS) and non-Microsoft platforms such as Cisco, Checkpoint, Palo Alto, and others.

IKEv2 Limitations

IKEv2 is clearly the protocol of choice in terms of security. It supports modern cryptography and is highly resistant to interception. It’s not without some operational challenges, however. Consider the following.

Firewalls

IKEv2 uses UDP ports 500 and 4500 for communication. Unfortunately, these ports are not always open. Often, they are blocked by network administrators to prevent users from bypassing security controls or attackers from exfiltrating data.

Fragmentation

IKEv2 packets can become quite large at times, especially when using client certificate authentication with the Protected Extensible Authentication Protocol (PEAP). This can result in fragmentation occurring at the network layer. Unfortunately, many firewalls and network devices are configured to block IP fragments by default. This can result in failed connection attempts from some locations but not others.

Load Balancing

Load balancing IKEv2 connections is not entirely straightforward. Without special configuration, load balancers can cause intermittent connectivity issues for Always On VPN connections. Guidance for configuring IKEv2 load balancing on the Kemp LoadMaster and the F5 BIG-IP can be found here:

IKEv2 Fragmentation

IKEv2 fragmentation can be enabled to avoid IP fragmentation and restore reliable connectivity. IKEv2 fragmentation is supported in Windows 10 and Windows Server beginning with v1803. Guidance for enabling IKEv2 fragmentation on Windows Server RRAS can be found here. Support for IKEv2 fragmentation on non-Microsoft firewall/VPN devices is vendor-specific. Consult with your device manufacturer for more information.

IKEv2 Security and RRAS

Be advised that the default security settings for IKEv2 on Windows Server RRAS are very poor. The minimum recommended security settings and guidelines for implementing them can be found here.

IKEv2 or TLS?

IKEv2 is recommend for deployments where the highest level of security and protection is required for remote connections. In these scenarios, the sacrifice of ubiquitous availability in favor of ultimate security might be desired.

SSTP or another TLS-based VPN protocol is recommended if reliable operation and connectivity are desired. SSTP and TLS VPNs can be configured to provide very good security by following the security and implementation guidelines found here.

IKEv2 with TLS Fallback

In theory, preferring IKEv2 and falling back to the Secure Socket Tunneling Protocol (SSTP) or another TLS-based VPN protocol when IKEv2 is unavailable would seem like a logical choice. This would ensure the highest level of protection, while still providing reliable connectivity. Unfortunately, the Windows VPN client doesn’t work this way in practice. Details here.

Additional Information

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

Windows 10 Always On VPN IKEv2 Load Balancing with Kemp LoadMaster

Windows 10 Always On VPN IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 and SSTP Fallback

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS

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.

$Namespace = “root\cimv2\mdm\dmmap”
$ClassName = “MDM_VPNv2_01”

$obj = Get-CimInstance -Namespace $Namespace -ClassName $ClassName
Remove-CimInstance -CimInstance $obj

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

 

Always On VPN Device Tunnel Configuration using Intune

Always On VPN Device Tunnel Configuration using IntuneA while back I described in detail how to configure a Windows 10 Always On VPN device tunnel connection using PowerShell. While using PowerShell is fine for local testing, it obviously doesn’t scale well. In theory you could deploy the PowerShell script and XML file using System Center Configuration Manager (SCCM), but using Microsoft Intune is the recommended and preferred deployment method. However, as of this writing Intune does not support device tunnel configuration natively. The administrator must create a ProfileXML manually and use Intune to deploy it.

Device Tunnel Prerequisites

I outlined the Always On VPN device tunnel prerequisites in my previous post here. To summarize, the client must be running Windows 10 Enterprise edition and be domain-joined. It must also have a certificate issued by the internal PKI with the Client Authentication EKU in the local computer certificate store.

ProfileXML

To begin, create a ProfileXML for the device tunnel that includes the required configuration settings and parameters for your deployment. You can find a sample Windows 10 Always On VPN device tunnel ProfileXML here.

Note: Be sure to define a custom IPsec policy in ProfileXML for the device tunnel. The default security settings for the IKEv2 protocol (required for the device tunnel) are quite poor. Details here.

Intune Deployment

Open the Intune management console and follow the steps below to deploy an Always On VPN device tunnel using Microsoft Intune.

Create Profile

1. Navigate to the Intune portal.
2. Click Device configuration.
3. Click Profiles.
4. Click Create profile.

Define Profile Settings

1. Enter a name for the VPN connection in the Name field.
2. Enter a description for the VPN connection in the Description field (optional).
3. Select Windows 10 and later from the Platform drop-down list.
4. Select Custom from the Profile type drop-down list.

Always On VPN Device Tunnel Configuration using Intune

Define Custom OMA-URI Settings

1. On the Custom OMA-URI Settings blade click Add.
2. Enter a name for the device tunnel in the Name field.
3. Enter a description for the VPN connection in the Description field (optional).
4. Enter the URI for the device tunnel in the OMA-URI field using the following syntax. If the profile name includes spaces they must be escaped, as shown here.

./Device/Vendor/MSFT/VPNv2/Example%20Profile%Name/ProfileXML

5. Select String (XML file) from the Data Type drop-down list.
6. Click the folder next to the Select a file field and chose the ProfileXML file created previously.
7. Click Ok twice and then click Create.

Always On VPN Device Tunnel Configuration using Intune

Assign Profile

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

1. Click Assignments.
2. Click Select groups to include.
3. Select the group that includes the Windows 10 client devices.
4. Click Select.
5. Click Save.

Always On VPN Device Tunnel Configuration using Intune

Demonstration Video

A video demonstration of the steps outlined above can be viewed here.

Additional Information

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN IKEv2 Security Configuration

Deleting a Windows 10 Always On VPN Device Tunnel

Windows 10 Always On VPN Device Tunnel Missing in the UI

Video: Deploying Windows 10 Always On VPN User Tunnel with Microsoft Intune

Always On VPN Device Tunnel Does Not Connect Automatically

When configuring a Windows 10 Always On VPN device tunnel, the administrator may encounter a scenario in which the device tunnel does not connect automatically. This can occur even when ProfileXML is configured with the AlwaysOn element set to “true”.

Always On VPN Device Tunnel Does Not Connect Automatically

Manual Connection

An administrator can establish a device tunnel connection manually using rasdial.exe however, indicating no issues with connectivity or authentication that would prevent a successful automatic connection.

Always On VPN Device Tunnel Does Not Connect Automatically

Root Cause

This scenario will occur when the device tunnel configuration is applied to a Windows 10 Professional edition client.

Always On VPN Device Tunnel Does Not Connect Automatically

Device Tunnel Support

The Windows 10 Always On VPN device tunnel is supported only on Windows 10 1709 or later Enterprise edition clients that are domain-joined. To ensure the device tunnel connects automatically, upgrade to Windows 10 Enterprise 1709 or later and join it to a domain.

Always On VPN Device Tunnel Does Not Connect Automatically

Source: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config#device-tunnel-requirements-and-features

Additional Information

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

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

Deleting a Windows 10 Always On VPN Device Tunnel

Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Always On VPN IKEv2 Load Balancing with F5 BIG-IPThe Internet Key Exchange version 2 (IKEv2) is the protocol of choice for Always On VPN deployments where the highest level of security is required. Implementing Always On VPN at scale often requires multiple VPN servers to provide sufficient capacity and to provide redundancy. Commonly an Application Delivery Controller (ADC) or load balancer is configured in front of the VPN servers to provide scalability and high availability for Always On VPN.

Load Balancing IKEv2

In a recent post I described some of the unique challenges load balancing IKEv2 poses, and I demonstrated how to configure the Kemp LoadMaster load balancer to properly load balance IKEv2 VPN connections. In this post I’ll outline how to configure IKEv2 VPN load balancing on the F5 BIG-IP load balancer.

Note: This article assumes the administrator is familiar with basic F5 BIG-IP load balancer configuration, such as creating nodes, pools, virtual servers, etc.

Initial Configuration

Follow the steps below to create a virtual server on the F5 BIG-IP to load balance IKEv2 VPN connections.

Pool Configuration

To begin, create two pools on the load balancer. The first pool will be configured to use UDP port 500, and the second pool will be configured to use UDP port 4500. Each pool is configured with the VPN servers defined as the individual nodes.

Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Virtual Server Configuration

Next create two virtual servers, the first configured to use UDP port 500 and the second to use UDP port 4500.

Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Persistence Profile

To ensure that both IKEv2 UDP 500 and 4500 packets are delivered to the same node, follow the steps below to create and assign a Persistence Profile.

1. Expand Local Traffic > Profiles and click Persistence.
2. Click Create.
3. Enter a descriptive name for the profile in the Name field.
4. Select Source Address Affinity from the Persistence Type drop-down list.
5. Click the Custom check box.
6. Select the option to Match Across Services.
7. Click Finished.

Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Assign the new persistence profile to both UDP 500 and 4500 virtual servers. Navigate to the Resources tab on each virtual server and select the new persistence profile from the Default Persistence Profile drop-down list. Be sure to do this for both virtual servers.

Always On VPN IKEv2 Load Balancing with F5 BIG-IP

Additional Resources

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

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN and IKEv2 Fragmentation

Windows 10 Always On VPN Certificate Requirements for IKEv2

Video: Windows 10 Always On VPN Load Balancing with the Kemp LoadMaster Load Balancer

Troubleshooting Always On VPN Error Code 809

When testing an Always On VPN connection, the administrator may encounter a scenario where the VPN client fails to connect to the VPN server. On the Windows 10 client the error message states the following.

“Can’t connect to [connection name]. The network connection between your computer and the VPN server could not be established because the remote server is not responding. This could be because one of the network devices (e.g. firewalls, NAT, routers, etc.) between your computer and the remote server is not configured to allow VPN connections. Please contact your Administrator or your service provider to determine which device may be causing the problem.”

Always On VPN and IKEv2 Fragmentation

In addition, the Application event log records an error message with Event ID 20227 from the RasClient source. The error message states the following.

“The User [username] dialed a connection named [connection name] with has failed. The error code returned on failure is 809.”

Troubleshooting Always On VPN Error Code 809

Connection Timeout

The error code 809 indicates a VPN timeout, meaning the VPN server failed to respond. Often this is related directly to network connectivity, but sometimes other factors can come in to play.

Troubleshooting VPN Error Code 809

When troubleshooting VPN error code 809 the following items should be carefully checked.

  • Name Resolution – Ensure the VPN server’s public hostname resolves to the correct IP address.
  • Firewall Configuration – Confirm the edge firewall is configured properly. Inbound TCP port 443 is required for the Secure Socket Tunneling Protocol (SSTP) and inbound UDP ports 500 and 4500 are required for the Internet Key Exchange version 2 (IKEv2) protocol. Make sure that any NAT rules are forwarding traffic to the correct server.
  • Load Balancer Configuration – If VPN servers are located behind a load balancer, make certain that virtual IP address and ports are configured correctly and that health checks are passing. For IKEv2 specifically, it is crucial that UDP ports 500 and 4500 be delivered to the same backend server. This commonly requires custom configuration. For example, on the KEMP LoadMaster the administrator will configure “port following”. On the F5 BIG-IP a  custom “persistence profile” must be configured. On the Citrix NetScaler a “persistency group” must be defined.

IKEv2 Fragmentation

VPN error code 809 can also be caused by IKE fragmentation when using the IKEv2 VPN protocol. During IKEv2 connection establishment, payload sizes may exceed the IP Maximum Transmission Unit (MTU) for the network path between the client and server. This causes the IP packets to be fragmented. However, it is not uncommon for intermediary devices (routers, NAT devices, or firewalls) to block IP fragments. When this occurs, a VPN connection cannot be established. However, looking at a network trace of the connection attempt, the administrator will see that the connection begins but subsequently fails.

Troubleshooting Always On VPN Error Code 809

Enable IKEv2 Fragmentation Support

The IKEv2 protocol includes support for fragmenting packets at the IKE layer. This eliminates the need for fragmenting packets at the IP layer. IKEv2 fragmentation must be configured on both the client and server.

Client

IKEv2 fragmentation was introduced in Windows 10 1803 and is enabled by default. No client-side configuration is required.

Server

IKEv2 is commonly supported on many firewall and VPN devices. Consult the vendor’s documentation for configuration guidance. For Windows Server Routing and Remote Access (RRAS) servers, IKEv2 fragmentation was introduced in Windows Server 1803 and is also supported in Windows Server 2019. It is enabled via a registry key. The following PowerShell command can be used to enable IKEv2 fragmentation on supported servers.

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\” -Name EnableServerFragmentation -PropertyType DWORD -Value 1 -Force

Validation

Once IKEv2 fragmentation is configured on the VPN server, a network capture will reveal the IKE_SA_INIT packet now includes the IKEV2_FRAGMENTATION_SUPPORTED notification message.

Always On VPN and IKEv2 Fragmentation

Additional Information

Windows 10 Always On VPN and IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN Hands-On Training Classes

%d bloggers like this: