The Network Policy Server (NPS) event log is incredibly valuable for administrators when troubleshooting Always On VPN user tunnel connectivity issues. Administrators can find these pertinent events by opening the Event Viewer on the NPS server (eventvwr.msc) and navigating to Custom Views > Server Roles > Network Policy and Access Services.
Event Logs
When configured correctly, event logs will record the disposition of all authentication requests, allowed or denied. The two most common recorded events are event IDs 6272 (access granted) and 6273 (access denied).
NPS Event ID 6272 – Access granted.
NPS Event ID 6273 – Access denied.
Auditing
In some cases, administrators may find none of these events recorded even though user authentication is working correctly. Here, the only events recorded are NPS informational events indicating which domain controller the NPS server is using to perform authentication.
The lack of 6272 and 6273 events in the event log indicates that auditing for NPS events is not enabled. Open an elevated PowerShell window and run the following command to view the current auditing setting for NPS events.
Alternatively, consider using Active Directory group policy to enforce the NPS server auditing settings. Open the Group Policy Management Console (GPMC) and create a new GPO. Next, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff > Audit Network Policy Server and select the option to audit both success and failure attempts.
Once complete, link this GPO to the OU where the NPS servers reside.
Missing Events
If auditing is enabled and there are no recorded 6272 or 6273 events, the NPS server did not receive any authentication requests from the VPN server. Review the event logs on any other NPS servers if there is more than one configured. In addition, this may indicate that network communication between the VPN and NPS server is blocked. Ensure network connectivity and name resolution are working as expected.
Troubleshooting Guides
Are you interested in learning more about Always On VPN troubleshooting? My Always On VPN book contains an entire chapter dedicated to troubleshooting. Also, my Always On VPN video training course on Pluralsight includes a module on troubleshooting. The video training course is available to Pluralsight subscribers only. If you don’t have a Pluralsight subscription, you can sign up for a free trial here.
Recently 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).
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.
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.
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.
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.
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.
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.
Important! Updated April 29, 2020 to resolve an issue where the DirectAccess RADIUS encryption certificate was not published to the DirectAccess Server Settings GPO in Active Directory.
When DirectAccess is deployed using the Getting Started Wizard (GSW), sometimes referred to as the “simplified deployment” method, self-signed certificates are created during the installation and used for the IP-HTTPS IPv6 transition technology, the Network Location Server (NLS), and for RADIUS secret encryption. Administrators may also selectively choose to use self-signed certificates for IP-HTTPS, or when collocating the NLS on the DirectAccess server. The RADIUS encryption certificate is always self-signed.
Certificate Expiration
These self-signed certificates expire 5 years after they are created, which means many DirectAccess administrators who have used this deployment option will need to renew these certificates at some point in the future. Unfortunately, there’s no published guidance from Microsoft on how to accomplish this. However, the process is simple enough using PowerShell and the New-SelfSignedCertificate cmdlet.
PowerShell Script on GitHub
The PowerShell script to renew DirectAccess self-signed certificates has been published on GitHub. You can download Renew-DaSelfSignedCertificates.ps1 here.
Important Considerations
When the IP-HTTPS certificate is renewed using this script, DirectAccess clients outside will be immediately disconnected and will be unable to reconnect until they update group policy. This will require connecting to the internal network locally or remotely using another VPN solution. The NLS and RADIUS encryption certificates can be updated without impacting remote users.
In addition, internal clients that are not online when this change is made will be unable to access internal resources by name until they update group policy. If this happens, delete the Name Resolution Policy Table (NRPT) on the client using the following PowerShell command and reboot to restore connectivity.
Recently I wrote about 
Important! Updated April 29, 2020 to resolve an issue where the DirectAccess RADIUS encryption certificate was not published to the DirectAccess Server Settings GPO in Active Directory.
