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.
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.
Zero Trust Network Access (ZTNA) is a term that administrators are likely familiar with, as it is one of the hottest marketing buzzwords in circulation today. ZTNA can mean different things depending on the deployment scenario. ZTNA is fundamentally about enforcing the principle of least privilege for endpoints connecting remotely to the corporate network when it comes to enterprise mobility and remote access.
Trusted Access
Historically, VPNs and even DirectAccess granted full, unrestricted network access to authenticated devices and users. Once the endpoint has an IP address, and in the absence of other controls (routing limitations, firewall access controls, etc.), the user could access any resource on the internal network. The rationale was that authenticated devices and users should be considered “trusted”.
Limitations
The Trusted Access model has some significant limitations. It assumes that all traffic from authorized users and devices is legitimate. However, if an endpoint is compromised, an attacker has broad access to the internal network, which is not ideal from a security perspective.
Zero Trust
Zero Trust Network Access is a concept where administrators define explicitly the minimum level of access required to support remote workers. Instead of granting full network access to the endpoint, controlling access using fine-grained policies is enforced on the VPN connection. Configuring limited network access for Always On VPN clients dramatically reduces exposure of the internal network to compromised endpoints.
ZTNA Management
There is a significant management burden associated with this approach, however. Administrators must identify each application requiring VPN access and determine all associated protocols and ports to be allowed, and internal resources to which they will communicate. Although this task isn’t difficult if clients require access to a small subset of internal resources, it can be a substantial undertaking if clients require access to many internal resources from numerous client applications.
Moving Targets
Making things more challenging is that application and network infrastructure often change constantly, requiring administrators to manage network access continually to ensure application availability. When adding new applications or changing the internal infrastructure, updating the configuration on all remote endpoints will be required.
Updating Always On VPN configuration for devices managed with Microsoft Endpoint Manager (formerly Intune) isn’t difficult. However, it can be more challenging when using PowerShell with System Center Configuration Manager (SCCM) or another endpoint management platform.
Traffic Filters
ZTNA can be configured with Always On VPN using Traffic Filters. With Traffic Filters, administrators can apply fine-grained access control for VPN traffic based on a combination of the following.
Source IP address (IP address, address range, or subnet)
Destination IP address (IP address, address range, or subnet)
Protocol (TCP, UDP, IP, etc.)
Source Port
Destination Port
Endpoint Manager Configuration
Configuring Traffic Filters for Always On VPN connections can be performed using Microsoft Endpoint Manager. Open the Endpoint Manager management console (https://endpoint.microsoft.com), navigate to the Always On VPN device configuration profile, then perform the following steps.
Expand App and Traffic Rules.
Click Add next to Network traffic rules for this VPN connection.
Enter a descriptive name in the Name field.
Select Split tunnel from the Rule type drop-down list.
Enter “6” in the Protocol field.
Enter “3389” in the Lower port and Upper port fields in the Remote port ranges section.
Enter an IPv4 address in the Lower IPv4 address field.
Enter an IPv4 address in the Upper IPv4 address field. Enter the same IPv4 address as the lower address to specify a single host.
Click Save.
The example above shows a traffic filter restricting access to TCP port 3389 (Remote Desktop Protocol) from all VPN clients to the 172.16.0.0/24 network.
Note: Repeat these steps to create as many traffic filters as required for any processes or applications that must communicate over the Always On VPN connection.
XML Configuration
Traffic Filters can also be configured using custom XML. To implement the same Traffic Filter described previously, add the following code between the <VPNProfile> and </VPNProfile> tags in your XML configuration file.
Note: Address ranges used in Traffic Filters can be defined using CIDR notation in XML, but they are not supported using Microsoft Endpoint Manager today.
Default Deny
When configuring a Traffic Filter for an Always On VPN profile, an implicit “deny all” rule is automatically enabled. Any traffic not explicitly defined in a Traffic Filter will be denied, including unsolicited inbound traffic, which has crucial implications for the device tunnel because it is used commonly for system management of remote devices.
Direction
Traffic Filters are enabled for the Outbound direction only, by default. Beginning with Windows 10 2004, Microsoft introduced support for Inbound traffic filters. Before Windows 10 2004, configuring a Traffic Filter on the device tunnel would break manage-out scenarios by denying all unsolicited inbound network access.
As of this writing, configuring inbound Traffic Filters using Microsoft Endpoint Manager is not supported. They are only configurable using custom XML.
To implement a Traffic Filter to allow inbound RDP access from the internal network over the device tunnel, add the following code between the <VPNProfile> and </VPNProfile> tags in your XML configuration file.
Note: When configuring inbound Traffic Filters, specify the port of the listening process or application using the LocalPortRanges field.
Application Filters
Administrators can combine Application Filters with Traffic Filters to control network access over the Always On VPN connection even more granularly. Applications can be defined by the following.
Package Family Name (PFN) – This is the unique name of a Microsoft Store application. Use the Get-AppxPackage PowerShell command to find the PFN for an application.
File Path – This is the full path to any executable on the file system. For example, c:\Windows\System32\mstsc.exe.
SYSTEM – This allows Windows kernel-mode drivers (such as ping.exe and net.exe) to send traffic over the Always On VPN connection.
As of this writing, configuring Application Filters using Microsoft Endpoint Manager is not supported. They are only configurable using custom XML.
Application Filter Examples
Below are three examples showing different Application Filters based on file path, Package Family Name, and SYSTEM.
File Path
This example shows a Traffic Filter configured to allow RDP access to an internal subnet using the native Windows Remote Desktop client (mstsc.exe).
Note: Ping uses ICMP (IP protocol 1), which is a network layer protocol. As such, defining ports for the filter is not required.
IPv6 Compatibility
Sadly, the filtering techniques described in this article do not work when also configuring IPv6 on the Always On VPN connection. As of this writing, enabling Traffic Filters when an IPv6 address is assigned to the VPN interface is not supported. More details can be found here.
Configuring Zero Trust Network Access (ZTNA) with Windows 10 Always On VPN is not trivial. Still, with attention to detail, it can be a highly effective tool to enforce fine-grained network access policies and reduce exposure of the internal network to compromised endpoints. Combining Traffic Filters with Application Filters allows administrators to tightly control Always On VPN access and ensure the principle of least privilege is applied.
Using Traffic Filters with Always On VPN provides administrators the option to configure a true Zero Trust Network Access (ZTNA) solution for their field-based users and devices. By enabling traffic filtering, network access over the Always On VPN connection can be controlled using fine-grained policies. Traffic Filter rules can be configured to restrict access based source and destination IP addresses, protocols, and source and destination ports. Administrators can further restrict access based on the application generating the traffic.
IPv6
While testing these features recently, I learned that the Microsoft Endpoint Manager (formerly Intune) user interface does not appear to support IPv6 when configuring traffic filter rules. As you can see here, the UI explicitly asks for an IPv4 address and complains when entering an IPv6 address in the address field, as shown here.
Interestingly, it is possible to add IPv6 addresses in XML, as follows.
Unfortunately, after loading the XML on a test client, the Always On VPN connection fails with the following error message.
“Can’t connect to <ConnectionName>. Catastrophic failure.”
In addition, the Application event log records an event ID 20227 from the RasClient source with the following error.
“The user <UserName> dialed a connection name <ConnectionName> which has failed. The error code returned on failure is -2147418113.”
Workaround
At this time, the only known workaround is to update the configuration on the RRAS server to use IPv4 addressing for VPN clients.
Summary
Unfortunately, IPv6 is still a second-class citizen when it comes to Always On VPN. Although enabling IPv6 works well in most common deployment scenarios, the Microsoft Endpoint Manager management console often fails to accept IPv6 entries in IP address fields. In addition, some advanced features such as traffic filtering are incompatible with IPv6.
Web proxy servers are not as common today as they once were, but a few organizations still leverage them to provide secure Internet access for their employees. Commonly they are used to inspect and control Internet traffic and to enforce acceptable use policies. Some organizations may wish to extend this protection to Always On VPN clients in the field by enabling force tunneling. Administrators can define a web proxy server for Always On VPN connections globally for web traffic or individual websites or domains.
VPN Proxy
A VPN web proxy server can be defined when the Always On VPN user tunnel connection uses force tunneling. Although you can still configure a VPN web proxy server with split tunneling enabled, it will not work. It is only functional when force tunneling is in use.
Administrators can configure a VPN web proxy server using the Microsoft Endpoint Manager UI or custom XML deployed with Endpoint Manager or PowerShell. Administrators can define a VPN web proxy server explicitly, or a proxy automatic configuration (PAC) file can be specified.
Note: VPN proxy server settings only work when force tunneling is enabled. Force tunneling is an unsupported configuration for the device tunnel, making the global proxy server setting for the device tunnel unsupported.
Proxy Autoconfiguration
Perform the following steps to configure a VPN web proxy server with a PAC file in Endpoint Manager.
Expand the Proxy section in the Configuration settings of the Always On VPN configuration profile.
Enter the URL for the PAC file in the Automatic configuration script field. Be sure to include the port number in the URL when using a non-standard port.
Leave the Address and Port number fields blank.
Choose Enable or Disable from the Bypass proxy for local addresses drop-down list.
To configure a VPN web proxy server with a PAC file using custom XML, include the following code between the <VPNProfile> and </VPNProfile> tags in the Always On VPN XML configuration file.
Explicit Proxy
Perform the following steps to configure an explicit VPN web proxy server in Endpoint Manager.
Enter the IP address, hostname, or fully qualified domain name (recommended) in the Address field.
Enter the port number in the Port number field.
Choose Enable or Disable from the Bypass proxy for local addresses drop-down list.
To configure an explicit VPN web proxy server using custom XML, include the following code between the <VPNProfile> and </VPNProfile> tags in the Always On VPN XML configuration file.
Namespace Proxy
Administrators can also define VPN web proxy servers on a per-namespace or per-hostname basis. Namespace VPN proxy servers can be helpful for scenarios where routing public websites over the Always On VPN connection is required. Most commonly, this is necessary because the public website restricts access to the IP address of the on-premises Internet gateway.
A namespace VPN proxy server is implemented using a Name Resolution Policy Table (NRPT) rule. At the time of this writing, a bug in Microsoft Endpoint Manager prevents administrators from deploying this option using the UI.
As you can see here, administrators can specify a proxy server as part of an NRPT rule in the Endpoint Manager UI. Notice this section of the UI validates the proxy FQDN correctly.
However, when you try to save the configuration profile, Endpoint Manager returns the following error.
“Unable to save due to invalid data. Update your data then try again: ProxyServerUri must be a valid URL or be empty.”
Interestingly, when entering a URL such as http://proxy.lab.richardhicks.net:8080/ in the Proxy field, the Endpoint Manager UI accepts it and successfully validates. But according to the VPNv2 Configuration Service Provider (CSP) reference, the value must be entered as an IP address. A hostname or FQDN also works based on my testing. Entering a URL as shown in the example above will not work at all.
With that, the only way to implement a namespace VPN web proxy server is to use custom XML. To do this, include the following code between the <VPNProfile> and </VPNProfile> tags in the Always On VPN XML configuration file.
Include the leading “.” to specify the entire domain, as shown above. Omit the leading “.” to specify an individual host (for example, app.richardhicks.com). Repeat this section for each additional host or domain, as required.
Caveat
Unfortunately, the Microsoft Internet Explorer web browser is the only browser that functions with the namespace VPN web proxy server. All modern web browsers, including Microsoft Edge, ignore the namespace proxy setting entirely, which seriously limits this feature’s usefulness in most organizations today.
Workaround
If routing a public website over the Always On VPN tunnel is required, adding its IP address(es) to the Always On VPN connection’s routing table is needed. However, doing this presents some unique challenges, as public websites frequently have many IP addresses, which are often dynamically changing. Also, it is common for public websites to pull content from many different domains or use Content Delivery Networks (CDNs), making the problem of identifying which IP addresses to add to the Always On VPN connection’s routing table even more challenging. Further, administrators must update the client configuration each a public website’s IP address changes, adding significant management overhead.
Summary
Routing client Internet traffic through an on-premises web proxy server for Always On VPN clients works well when force tunneling is enabled. Administrators can explicitly define a web proxy server or use a proxy automatic configuration (PAC) file. All web browsers work without issue in this scenario. Using a namespace proxy is only effective when browsing with Microsoft Internet Explorer. All modern web browsers, including Microsoft Edge, ignore namespace proxy settings.
When using Windows Server Routing and Remote Access Service (RRAS) to terminate Always On VPN client connections, administrators can leverage the Secure Socket Tunneling Protocol (SSTP) VPN protocol for client-based VPN connections. SSTP is a Microsoft proprietary VPN protocol that uses Transport Layer Security (TLS) to secure connections between the client and the VPN gateway. SSTP provides some crucial advantages over IKEv2 in terms of operational reliability. It uses the TCP port 443, the standard HTTPS port, which is universally available and ensures Always On VPN connectivity even behind highly restrictive firewalls.
TLS Certificate
When configuring SSTP, the first thing to consider is the certificate installed on the server. A certificate with an RSA key is most common, but for SSTP, provisioning a certificate with an ECDSA key is recommended for optimal security and performance. See the following two articles regarding SSTP certificate requirements and ECDSA Certificate Signing Request (CSR) creation.
Much like IKEv2, the default TLS security settings for SSTP are less than optimal. However, SSTP can provide excellent security with some additional configuration.
TLS Protocols
There are several deprecated TLS protocols enabled by default in Windows Server. These include SSLv3.0, TLS 1.0, and TLS 1.1. They should be disabled to improve security for TLS. To do this, open an elevated PowerShell window on the VPN server and run the following commands.
Many weak TLS cipher suites and enabled by default in Windows Server. To further enhance security and performance, they can be optimized using a tool such as IIS Crypto. For example, consider prioritizing cipher suites that use ECDHE and GCM with ECDSA to improve security. Also, remove ciphers that use AES-256 to enhance scalability and performance.
Note: AES-256 does not provide any additional practical security over AES-128. Details here.
PowerShell Script
I have published a PowerShell script on GitHub that performs security hardening and TLS cipher suite optimization to streamline the configuration TLS on Windows Server RRAS servers. You can download the script here.
Validation Testing
After running the script and restarting the server, visit the SSL Labs Server Test site to validate the configuration. You should receive an “A” rating, as shown here.
Note: An “A” rating is not achievable on Windows Server 2012 or Windows Server 2012 R2 when using an RSA TLS certificate. A TLS certificate using ECDSA is required to receive an “A” rating on these platforms.
Windows Autopilot is a cloud-based technology that administrators can use to configure new devices wherever they may be, whether on-premises or in the field. Devices provisioned with Autopilot are Azure AD joined by default and managed using Microsoft Endpoint Manager. Optionally, an administrator can enable hybrid Azure AD join by also joining the device to an on-premises Active Directory domain using a domain join configuration profile in conjunction with the offline domain-join connector. Although enabling hybrid Azure AD join might sound appealing, there are specific deployment scenarios that present some rather unique and challenging problems when using this option.
Offline Hybrid Azure AD Join
For field-based devices, the device must have connectivity to a domain controller to support the initial login when the user has no local cached credentials. The Always On VPN device tunnel can be deployed in this scenario to provide connectivity and allow the user to log in to a new device the first time without being on-premises. The Always On VPN device tunnel is easily deployed using a Microsoft Endpoint Manager configuration profile. Certificates required to support the device tunnel can be deployed with Microsoft Endpoint Manager and one of the certificate connectors for Microsoft Endpoint Manager.
Windows 10 Professional
If a Windows 10 Professional device is configured using Autopilot, and hybrid Azure AD joined is enabled, the Always On VPN device tunnel can still be provisioned, but it won’t start automatically because it requires Enterprise Edition to be fully functional. This prevents the user from being able to logon the first time. The device must be upgraded to Enterprise Edition before the first user logon. There are multiple ways to accomplish this depending on the deployment scenario and activation requirements.
Multiple Activation Key
The easiest way to upgrade Windows 10 Professional to Enterprise Edition is to obtain a Multiple Activation Key (MAK) and deploy that to clients using a Microsoft Endpoint Manager configuration profile. Follow the steps below to create a configuration profile to perform this upgrade.
Open the Microsoft Endpoint Manager console and click on Devices > Configuration Profiles.
Click Create profile.
Select Windows 10 and later in the Platform drop-down list.
Select Templates in the Profile type drop-down list.
Select Edition upgrade and mode switch from the list of templates.
Click Create.
Use the following steps to configure the settings for the configuration profile.
Enter a descriptive name for the configuration profile in the Name field.
Enter a description for the profile in the Description field (optional).
Click Next.
Expand the Edition Upgrade section and select Windows 10 Enterprise from the Edition to upgrade to drop-down list.
Enter your multiple activation product key in the Product Key field.
Once complete, assign the configuration profile to the appropriate groups and click Create.
KMS Activation
If Key Management Service (KMS) activation is required, follow the steps listed previously for MAK. Enter the KMS client setup key for Windows 10 Enterprise which is NPPR9-FWDCX-D2C8J-H872K-2YT43. The device will complete KMS activation when it can connect to the on-premises KMS host.
Subscription Activation
Windows 10 Enterprise Edition licensing is included in some Microsoft 365 subscriptions. This poses a unique challenge for hybrid Azure AD join scenarios, however. Specifically, subscription activation is a “step-up” process that requires Windows 10 Professional to have been successfully activated previously. Also, this occurs after the user logs on, but the user cannot log on unless the device tunnel is active. Catch 22!
Workaround
A multi-step process is required to address the limitations imposed by subscription activation. To begin, the device must be upgraded to Enterprise Edition, so the device tunnel is available for the initial user logon. This is a temporary, one-time upgrade to Enterprise Edition solely for the purpose of getting the device tunnel to connect and allow the user to authenticate.
To begin, download this PowerShell script and follow the steps below to deploy it to Windows 10 devices using Microsoft Endpoint Manager.
Open the Microsoft Endpoint Manager console and click on Devices > Scripts.
Click Add and select Windows 10.
Enter a descriptive name for the configuration profile in the Name field.
Enter a description for the profile in the Description field (optional).
Click Next.
Enter the location of the PowerShell script in the Script location field.
Click Next, then assign the script to the appropriate device group(s) and click Add.
The PowerShell script will automatically install the KMS client setup key for Windows 10 Enterprise Edition, then restart the network interfaces to ensure the device tunnel starts. This will immediately upgrade the client device to Windows 10 Enterprise Edition and allow the user to authenticate.
Subscription activation with a step-up upgrade to Enterprise Edition still requires that Windows 10 Professional be activated first. To accomplish this, the embedded Windows 10 Professional key must be re-installed on the client. To do this, download this PowerShell script and follow the same steps listed previously to deploy a PowerShell script with Microsoft Endpoint Manager. However, this script should be assigned to users, not devices.
Once this script is run on the client it will be downgraded (temporarily) to Windows 10 Professional edition. After activation is successful, subscription activation will once again upgrade the client to Windows 10 Enterprise Edition.
Considerations
As you can see, the process of getting a Windows 10 Professional edition client onboarded in a hybrid Azure AD joined scenario is somewhat complex. My advice is to avoid this scenario whenever possible. Access to on-premises resources with the Always On VPN user tunnel with full single sign-on support is still available for users on Windows 10 devices that are Azure AD joined only. Unless there is a specific requirement to manage client devices using on-premises Active Directory and group policy, consider choosing native Azure AD join with Autopilot and manage devices using Microsoft Endpoint Manager exclusively.
Special Thanks
I would like to extend a special thank you to everyone in the Microsoft Endpoint Manager community who provided valuable input and feedback for me on this topic, especially John Marcum, Michael Niehaus, and Sandy Zeng. Follow the #MEMCM hashtag on Twitter to keep up on all things Microsoft Endpoint Manager.
Using the Extensible Authentication Protocol (EAP) with client certificates is the recommended best practice for authentication for Windows 10 Always On VPN deployments. EAP, and especially Protected EAP (PEAP), has a lot of settings to configure and it is not uncommon to encounter issues related to some parameters being defined incorrectly. This post covers one of the more common issues related to EAP/PEAP misconfiguration.
Action Needed?
When establishing an Always On VPN user tunnel connection, users may find the connection does not complete automatically, and they are informed that additional action is needed.
Clicking on the VPN connection and then clicking Connect prompts the user with the following message.
“Action needed. Continue connecting? We don’t have enough info to validate the server. You can still connect if you trust this server.”
Common Causes
This message can occur when (EAP) is used and is configured to perform server validation with a restricted set of NPS servers, as shown here.
NPS Server Certificate
The NPS server performing authentication for the connection request must have a certificate that includes a subject name that matches one of the names of the NPS servers defined in the EAP configuration. The certificate must be issued by the organizations private certification authority (CA).
EAP Configuration
Alternatively, the client-side EAP configuration may be incorrect. Although the NPS server may have the correct hostname configured on its certificate, it may not be entered correctly on the client. Ensure the hostname listed in the “Connect to these servers” field matches the subject name or SAN of the NPS server certificate defined in the network policy used for the Always On VPN user tunnel. Look carefully at the syntax when defining multiple NPS servers. Multiple servers are separated by a semi-colon and there are no additional spaces. Missing either one of these critical details will result in connection prompts. Also, ensure that all NPS servers used for authentication (those defined on the VPN server) are included in this list.
Note: Administrators must ensure that all VPN clients have updated their EAP configuration before adding additional NPS servers to the environment. Failure to do so will result in connection prompts.
Security Best Practice
To be clear, the behavior above is not ideal from a security perspective. Validating the NPS server before authenticating is crucial to ensuring the highest level of security and assurance, preventing credential theft from a man-in-the-middle attack. For this reason, it is recommended that users not be given the choice to authorize an NPS server. Authorized NPS servers should be defined by administrators exclusively. This is accomplished by selecting the option “Don’t ask user to authorize new servers or trusted CAs” in the Notifications before connecting drop-down list, and by selecting the option “Don’t prompt user to authorize new servers or trusted certification authorities“.
When configuring a Windows Routing and Remote Access Service (RRAS) server to support Internet Key Exchange version 2 (IKEv2) VPN connections, it is essential for the administrator to define the root certification authority for which to accept IPsec security associations (SAs). Without defining this setting, the VPN server will accept a device certificate issued by any root certification authority defined in the Trusted Root Certification Authorities store. Details about configuring IKEv2 security and defining the root certification authority can be found here.
Multiple Root Certificates
Administrators may find that when they try to define a specific root certification authority, the setting may not be implemented as expected. This commonly occurs when there is more than one root certificate in the Trusted Root Certification Authorities store for the same PKI.
Certificate Selection
When running the PowerShell command Set-VpnAuthProtocol to define the root certification authority, PowerShell may ignore the administrator-defined certificate and choose a different one, as shown here. This will result in failed IPsec VPN connections from Windows 10 Always On VPN clients using IKEv2.
Certificate Publishing
This issue can occur when root certification authority certificates are published using Active Directory group policy. It appears that Windows prefers Active Directory group policy published certificates over those published directly in the Certification Authorities Container in Active Directory. To resolve this issue, remove any group policy objects that are publishing root certification authority certificates and ensure those root certificates are published in the Certification Authorities container in Active Directory.
PowerShell Script
A PowerShell script to configure this setting that can be found in my Always On VPN GitHub repository here. I have updated this script to validate the defined root certification authority certificate and warn the user if it does not match.
Microsoft recently made available an update for Windows 10 2004 that includes many important fixes for outstanding issues with Windows 10 Always On VPN. KB4571744 (build 19041.488) addresses many challenges faced by Always On VPN administrators today, including the following.
TPM
This update addresses an issue that prevents hash signing from working correctly using the Microsoft Platform Crypto Provider for Trusted Platform Module (TPM). This issue can occur when administrators configure Always On VPN to use Protected Extensible Authentication Protocol (PEAP) with client certificate authentication using a FortiGate security device.
Sleep/Hibernate
This update also addresses issues with Windows 10 Always On VPN failing to automatically reconnect when resuming from sleep or hibernate. I’ve written about issues with Always On VPN and sleep/hibernate in the past. This is an issue that has plagued Always On VPN since its introduction, so let’s hope this finally provides some meaningful relief from this persistent problem.
Certificate Authentication
When both the Always On VPN device tunnel and user tunnel are provisioned to a Windows 10 clients, user tunnel connections may be authenticated using the machine certificate and not EAP/PEAP. This can result in connections that are not validated as intended, and allowing a user to bypass configured NPS policies, MFA requirements, or conditional access rules. This update includes a fix for this issue, restoring proper authentication for the user tunnel when the device tunnel is also provisioned.
Device and User Tunnel Coexistence
A bug that first appeared when Windows 10 2004 was introduced prevented a device tunnel and user tunnel Always On VPN connection from being established to the same VPN server if the user tunnel used Internet Key Exchange Version 2 (IKEv2). This update restores full functionality under those conditions.
Update KB4571744
To resolve these issues with Windows 10 Always On VPN as well as others, download and install update KB4571744 today. If you are experiencing any of these issues with releases of Windows 10 prior to 2004, look for updates for those build to come later this year.
When configuring a Windows Routing and Remote Access Service (RRAS) server to support Internet Key Exchange version 2 (IKEv2) VPN connections, it is essential for the administrator to define the root certification authority for which to accept IPsec security associations (SAs). Without defining this setting, the VPN server will accept a device certificate issued by any root certification authority defined in the Trusted Root Certification Authorities store. Details about configuring IKEv2 security and defining the root certification authority can be found 
Microsoft recently made available an update for Windows 10 2004 that includes many important fixes for outstanding issues with Windows 10 Always On VPN. 
