When deploying Windows 10 Always On VPN using Protected Extensible Authentication Protocol (PEAP) with client authentication certificates, the administrator may encounter a scenario in which the user can establish a VPN connection without issue, but when accessing internal resources they are prompted for credentials and receive the following error message.
“The system cannot contact a domain controller to service the authentication request. Please try again later.”
Resolution
This can occur if one or more domain controllers in the enterprise have expired or missing domain controller authentication certificates. To ensure seamless single sign-on to internal resources, ensure that all domain controllers have a certificate issued by the internal certification authority (CA) that includes the Server Authentication (1.3.6.1.5.5.7.3.1), Client Authentication (1.3.6.1.5.5.7.3.2), KDC Authentication (1.3.6.1.5.2.3.5), and Smart Card Logon (1.3.6.1.4.1.311.20.2.2) Enhanced Key Usage (EKU). Administrators can duplicate the Kerberos Authentication template for this purpose.
Configuring Multifactor Authentication (MFA) is an excellent way to ensure the highest level of assurance for Always On VPN users. Azure MFA is widely deployed and commonly integrated with Windows Server Network Policy Server (NPS) using the NPS Extension for Azure MFA. Azure MFA has a unique advantage over many other MFA providers in that it supports MFA when using Protected Extensible Authentication Protocol (PEAP). This makes Azure MFA the solution of choice for integrating with Windows 10 Always On VPN deployments using client certificate authentication, a recommended security configuration best practice.
NPS Configuration
Installing and configuring the NPS extension for Azure MFA is straightforward. Configuration guidance from Microsoft can be found here.
Connection Issues
After installing the NPS extension for Azure MFA, administrators may find that Always On VPN connections fail and the user is never challenged for authentication. The connection eventually times out and returns the following error message.
“A connection to the remote computer could not be established, so the port used for this connection was closed.”
In addition, the Application event log on the Windows 10 client contains an Event ID 20221 from the RasClient source that includes the following error message.
“The user [username] dialed a connection named [connection] which has failed. The error code returned on failure is 0.”
NPS Event Log
Reviewing the event logs on the NPS server reveals more information. The Security event log contains an Event ID 6274 from the Microsoft Windows security auditing source that includes the following error message.
“Network Policy Server discarded the request for a user. Contact the Network Policy Administrator for more information.”
ESTS Token Error
Digging deeper in the operational event log on the NPS server, the AuthZAdminCh log (Applications and Services Logs > Microsoft > AzureMfa > AuthZ) contains an Event ID 3 from the AuthZ source indicating an ESTS_TOKEN_ERROR message.
Troubleshooting ESTS Token Error
Follow the steps below to troubleshoot the ESTS_TOKEN_ERROR.
Prerequisites
Ensure that all prerequisites are met. Validate the user is being synced to Azure Active Directory and that it is properly licensed for Azure MFA.
Certificates
As part of the NPS extension configuration, a certificate is created on the NPS server that is uploaded to Azure Active Directory. To validate the certificate was created and uploaded correctly, follow the troubleshooting guidance found here.
Enterprise Applications
The Azure Multi-Factor Auth Client and the Azure Multi-Factor Auth Connector enterprise applications must be enabled to support the NPS extension for Azure MFA. To confirm they are enabled, open an elevated PowerShell command window on the server where the Azure AD Connector is installed and run the following PowerShell commands.
The 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 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.
When deploying Windows 10 Always On VPN using Protected Extensible Authentication Protocol (PEAP) with client authentication certificates, the administrator may encounter a scenario in which the user can establish a VPN connection without issue, but when accessing internal resources they are prompted for credentials and receive the following error message.
Configuring Multifactor Authentication (MFA) is an excellent way to ensure the highest level of assurance for Always On VPN users. 
The 
