Always On VPN NPS Auditing and Logging

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.

auditpol.exe /get /subcategory:”Network Policy Server”

Open an elevated PowerShell window and run the following command to enable auditing for NPS events.

auditpol.exe /set /subcategory:”Network Policy Server” /success:enable /failure:enable

Group Policy

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.

Additional Information

Troubleshooting Always On VPN Errors 691 and 812

Troubleshooting Always On VPN Errors 691 and 812 – Part 2

Troubleshooting Always On VPN Errors 691 and 812 – Part 3

Always On VPN NPS Load Balancing

Always On VPN Error -2146762495

DirectAccess Troubleshooting and the Windows 10 Network Connectivity Assistant

Always On VPN Administrators may encounter a scenario where Always On VPN connections suddenly stop working for all clients using the Secure Socket Tunneling Protocol (SSTP) VPN protocol. IKEv2 VPN connections continue to work, however.

Event Log

Reviewing the event log on a client machine reveals an error event ID 20227 from the RasClient source. 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 -2146762495.”

Error -2146762495?

Always On VPN administrators will be familiar with error codes such as 809, 691 and 812, 853, 858, and even 13801, 13806, and 13868. However, this error code seems to be formatted much differently. As it turns out, this message is in decimal format. Thankfully it’s pretty easy to convert it to something more meaningful, like hexadecimal. To do this, open the Windows calculator (calc.exe) and switch to programmer mode. Highlight DEC and enter -2146762495. The hexadecimal value will be displayed in the HEX field, as shown here.

Error 0x800B0101

After converting the error message from decimal to hex, use the Microsoft Error Lookup tool (err.exe) to translate the hex value of this error. As shown here, 0x800B0101 translates to CERT_E_EXPIRED.

Expired TLS Certificate

Once again, an expired certificate is to blame! In this case, the TLS certificate installed on the VPN server has expired and is no longer valid.

Resolution

The problem is simple enough to resolve, of course. Obtain a new TLS certificate from your certification authority (CA) of choice and update your VPN server configuration. You can find detailed guidance for updating the RRAS VPN server’s TLS certificate here. You will also find a video demonstration of the RRAS SSL/TLS certificate renewal process here.

Additional Information

Installing or Renewing an SSL/TLS Certificate on Windows Server RRAS for Always On VPN and SSTP

VIDEO: Installing or Renewing an SSL/TLS certificate on Windows Server RRAS for Always On VPN and SSTP

Microsoft Windows Always On VPN SSTP Security Configuration

Microsoft Windows Always On VPN SSL/TLS Certificate Requirements for SSTP

Microsoft Windows Always On VPN SSTP with Let’s Encrypt Certificates