Always On VPN RRAS Internal Interface Non-Operational

Windows 10 Always On VPN Routing Configuration

Always On VPN administrators troubleshooting connectivity issues may find the Internal network interface in the Routing and Remote Access management console (rrasmgmt.msc) administrative status indicates ‘Unknown’. They will also notice the Operational Status shows Non-operational.

Internal Interface

For clarification, the ‘Internal’ network interface in the Routing and Remote Access management console, as shown above, is not a physical network adapter on the server. Instead, it is a virtual network interface used only for incoming VPN connections.

Non-Operational

The Internal virtual network interface will not be created until the VPN server accepts its first VPN connection. Because of this, the Internal interface will have an operational status of non-operational until the first client attempts to connect. When this occurs, RRAS creates the interface, then assigns it the first IP address from the static IPv4 address pool. Alternatively, if DHCP is configured, it will assign the first IP address returned by the DHCP server.

Interface Names

While discussing network interfaces, I typically recommend renaming them in Windows to identify their function, especially when using two NIC configurations. However, be careful not to name the server’s internal network adapter ‘Internal’, as this can be confusing in the future. In my example above, I use the name ‘LAN’ to identify the internal adapter to distinguish it from the server’s ‘Internal’ virtual interface.

Additional Information

Windows Server RRAS Service Does Not Start

Windows Server RRAS Monitoring and Reporting

Microsoft Always On VPN and RRAS in Azure

Microsoft Always On VPN and RRAS with Signle NIC

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 View > 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 > Local Policies > Audit Policy > Audit account logon events 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

%d bloggers like this: