Always On VPN – Troubleshooting

This post was updated on February 13th, 2021.

There are many issues that can happen while configuring and using an Always On VPN solution. In this post I’ll be covering the common errors I’ve encountered while setting up Always On VPN. In addition, I’ll share some useful commands and show to how monitor VPN connections. Also, make sure to check out the troubleshooting section of the official Microsoft Documentation.

Links to each individual post in this series can be found below.

Always On VPN – Basic Deployment Guide
Always On VPN – Certificates and Active Directory
Always On VPN – VPN and NPS Server Configuration
Always On VPN – User Tunnel
Always On VPN – Device Tunnel

VPN Connection Error Codes

The first thing I want to cover is the error codes you might encounter when attempting to establish a VPN connection. These errors can be found by looking in the Application event log on the client. The events will have a source of RasClient. A full list of RRAS error codes can be found here.

Error code: 691

This error can be caused by TLS 1.0 being disabled (Windows Server 2012 R2 and earlier) or by settings configured on the Dial-In tab of a user’s AD account. See this post and this post and this post for more information.

Error code: 800

This error is usually caused when a custom IKEv2 security policy is specified and the VPN connection type is set to automatic. See these links for more information. Microsoft, Richard Hicks

Error code: 809

This error is usually caused by the VPN client not being able to communicate with the VPN server. See these links for more information. Microsoft, Richard Hicks

Error code: 812

This is an error covered on the troubleshooting page of the Microsoft Documentation, but I wanted to add a few notes not mentioned there.

  • If attempting to connect a user tunnel, ensure the user account is a member of the AD group specified in the VPN policy on the NPS server
  • Ensure the VPN server is able to communicate with the NPS server. If the NPS server is running on Windows Server 2019, there is a bug where the Windows Firewall rules may not work correctly. To fix this bug, run this command from an administrative command prompt on the NPS server.
sc.exe sidtype IAS unrestricted

For more information about this bug and the solution, see this post.

Error code: 858

This error is caused by the certificate on the NPS server being expired. See this post for more information.

Error code: 864

This error is caused by an invalid or missing certificate on the NPS server. See this post for more information.

Error code: 902

  • Error description
    • The specified protocol identifier is not known to the router.
  • Possible cause
    • This error can occur when IPv6 has been disabled on the VPN server
  • Possible solutions
    • Ensure there is not a group policy object deployed to the VPN server that is disabling IPv6
    • Re-enable IPv6
      • In the registry on the VPN server, navigate to HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters and look for the value DisabledComponents
      • If this value exists, it should be set to either 0 (IPv6 enabled) or 32 (IPv6 enabled but IPv4 is preferred). If this value is set to anything other than 0 or 32, the Routing and Remote Access service will not work. After changing this value, reboot the VPN server.
      • For more information about this registry value, refer to this article.
    • If the error persists after re-enabling IPv6
      • In the registry on the VPN server, navigate to HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\RouterManagers There should be a key under RouterManagers named ipv6.
      • If this key does not exist, re-create it and then restart the Routing and Remote Access service

Error code: 13801

This error is usually caused by a missing, expired, or incorrectly configured machine certificate on the client or VPN server. See this post for more information.

Error code: 13806

This error is usually caused when using a device tunnel connection and the machine certificate is missing on either the client or server side. See this post for more information.

Error code: 13868

  • Error description
    • Policy match error
  • Possible cause
    • This error can occur when using the IKEv2 protocol and the IKEv2 security settings configured on the client don’t match the settings configured on the server.
  • Possible solutions
    • Ensure the IKEv2 security settings on the client and server match
      • Check the server settings by running this PowerShell command
        • Get-VpnServerIPsecConfiguration
      • Check the client settings by running this PowerShell command
        • Get-VpnConnection -Name “VPN Name” | Select-Object -ExpandProperty IPsecCustomPolicy
    • If you’ve been following my guide and implemented the improved IKEv2 security settings on the server, then running this command on the client should resolve the issue.
Set-VpnConnectionIPsecConfiguration -ConnectionName "VPN Name" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -Force

For more information about this error and my source for these commands, refer to this post.

Error code: 13899

  • Error description
    • Error in assigning inner IP address to initiator in tunnel mode
  • Possible cause
    • This error can occur when the VPN server is unable to assign an IP address to the VPN tunnel
  • Possible solutions
    • If the VPN server is configured to assign IP addresses from a static pool, check if all available addresses have been allocated. If so, add additional IP address space to the pool.
    • If the VPN server is configured to assign IP addresses using DHCP
      • Ensure a DHCP server is reachable from the VPN server
      • Ensure the DHCP scope has available IP addresses to allocate
    • If the VPN server is running Windows Server 2019 and is configured to assign IP addresses using DHCP, there is a bug that can cause this issue.
      • To resolve this issue, run the following command to create a new registry value, then reboot the VPN server
      • For more information about this bug, refer to this TechNet post.
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Dhcp" /v RequiredPrivileges /d "SeChangeNotifyPrivilege"\0"SeCreateGlobalPrivilege"\0"SeImpersonatePrivilege"\0 /t REG_MULTI_SZ /f

Error code: 0x80070040

This error is caused by a missing or incorrectly configured certificate on the VPN server. See this post for more information.

Error code: 0x80092013

This error is caused when using SSTP and the CRL of the SSL certificate installed on the VPN server is not publicly available. See this post for more information.

Error code: 0x800B0109

This error is caused when the root CA certificate that issued the client certificate is not installed in the Trusted Root Certification Authorities store on the client computer. See this post for more information.

VPN Connection Reliability (Sleep / Hibernate)

Many users have experienced issues with Always On VPN connections not reliably re-connecting when a device comes out of a sleep or hibernate mode. There is a lengthy TechNet forum post on the topic. Richard Hicks also has a post on the subject.

Device Tunnel with Multiple Root Certificates

It’s possible to have multiple copies of the same root certificate installed in the trusted root certificates store on the VPN server. This can cause issues with the authentication process for device tunnel connections. To resolve this issue, remove the duplicate certificates. Read more about this issue in this post by Richard Hicks.

VPN Creation Errors

These are errors you may encounter when using the New-AovpnDeviceTunnel.ps1 or New-AovpnUserTunnel.ps1 scripts to install a new VPN tunnel on a computer.

Both of these scripts write to a log file located in ProgramData\AOVPN. Make sure to check this log file for more details about why one of the scripts may have failed.

  • Error Message – Unable to get user SID. User may be logged on over Remote Desktop: A constructor was not found. Cannot find an appropriate constructor for type System.Security.Principal.NTAccount
    • This error is caused because the user tunnel cannot be created for a user that is logged in through a remote desktop session. The user must be locally logged into the computer or connected via a remote console session.
  • Error Message – Unable to create VPN Name profile: A general error occurred that is not covered by a more specific error code
    • This error is usually caused by invalid syntax in the XML file that was provided to the script. Review the XML file and correct any typos or incorrect formatting.

Name Resolution Policy Table (NRPT)

The Name Resolution Policy Table is used to specify DNS names or namespaces that require special handling during DNS lookups. In an AOVPN configuration, the NRPT is configured by specifying the <DomainNameInformation> element in the ProfileXML file. This can be a useful feature, however, there are a few things to be aware of when using the NRPT.

Troubleshooting Tools

When attempting to troubleshoot DNS with the NRPT enabled, be careful about using nslookup. Nslookup will bypass the NRPT and use the DNS servers configured on the network adapter. Instead of nslookup, use the Resolve-DNSName PowerShell cmdlet.

There are a few PowerShell cmdlets that can be used to view NRPT settings. (Get-DnsClientNrptPolicy, Get-DnsClientNrptGlobal, Get-DnsClientNrptRule)

#View the currently applied NRPT settings
Get-DnsClientNrptPolicy

#View the NRPT settings for a specific namespace
Get-DnsClientNrptPolicy -Effective -Namespace "example.corp.com"

#View the global NRPT settings on a device
Get-DnsClientNrptGlobal

#View currently configured NRPT rules
Get-DnsClientNrptRule

DNS Registration Issue

There is an issue when the NRPT is used and the ProfileXML has the <RegisterDNS> element set to True. In this case, the client may register 2 DNS entries, one for the IP of the VPN, and one for the public IP of the system. Microsoft has released patches to resolve this issue, but even with the patches, a registry key may still need to be created to stop this issue from happening.

New-ItemProperty -Path 'HKLM:SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\' -Name DisableNRPTForAdapterRegistration -PropertyType DWORD -Value 1 -Force

For more information on this issue, refer to this post.

NRPT and DirectAccess

If you’re migrating from DirectAccess to Always On VPN, you may run into an issue where the NRPT rules seem to be ignored on the device. A symptom of this issue is when running the Get-DnsClientNrptPolicy cmdlet, no results are returned, but running the Get-DnsClientNrptRule cmdlet does show results. To resolve this issue, remove the registry key that is used to store DirectAccess NRPT entries.

Remove-Item -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig' -Recurse -Force

Other Useful Commands

This is a list of some commands I’ve found useful for troubleshooting Always On VPN connections.

#Attempt to connect a VPN tunnel
rasdial "Tunnel Name"

#Attempt to disconnect a VPN tunnel
rasdial "Tunnel Name" /d

#List all user VPN connections
Get-VpnConnection

#List all device VPN connections
Get-VpnConnection -AllUserConnection

#Delete a user tunnel
Get-VpnConnection | Where Name -eq "Tunnel Name" | Remove-VpnConnection

#Delete a device tunnel
Get-VpnConnection -AllUserConnection | Where Name -eq "Tunnel Name" | Remove-VpnConnection

Monitor Active VPN Connections

There are 3 main ways to monitor active VPN connections when using Windows Server as a VPN server.

  • The Remote Access Management console
    • Open the Remote Access Management console and select Remote Client Status. This view gives the most information about the connected clients.
  • The Routing and Remote Access console
    • Open the Routing and Remote Access console and select Remote Access Clients. This view is like the first option, but less information is displayed.
  • PowerShell
    • Open PowerShell and run the Get-RemoteAccessConnectionStatistics cmdlet.