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.
When configuring Windows 10 Always On VPN using Extensible Authentication Protocol (EAP), the administrator may encounter a scenario in which the client connection fails. The event log will include an event ID 20227 from the RasClient source that includes the following error message.
“The user [domain\username] dialed a connection named [connection name] which has failed. The error code returned on failure is 858.”
RasClient Error 858
RasClient error code 858 translates to ERROR_EAP_SERVER_CERT_EXPIRED. Intuitively, this indicates that the Server Authentication certificate installed on the Network Policy Server (NPS) has expired. To resolve this issue, renew the certificate on the NPS server.
DirectAccess is an IPv6 only solution, at least from the perspective of the client. When the DirectAccess client is remote, it communicates with the DirectAccess server using IPv6 exclusively. IPv6 transition technologies are used to enable this connectivity when the DirectAccess server and/or client are on the pubic IPv4 Internet.
IP-HTTPS
One of the IPv6 transition technologies used by DirectAccess is IP-HTTPS. With IP-HTTPS, IPv6 traffic is encapsulated in HTTP and delivered to the DirectAccess server using IPv4. IP-HTTPS is used exclusively when the DirectAccess server is located behind an edge firewall performing network address translation.
SSL Certificate
To support IP-HTTPS, an SSL certificate is installed on each DirectAccess server. The SSL certificate is commonly issued by a public certification authority, but it can also be issued by an internal PKI. The SSL certificate used for IP-HTTPS can and does expire, and when it does it will prevent any DirectAccess connection from being established using this transition technology.
Troubleshooting
When troubleshooting DirectAccess connectivity via IP-HTTPS, the first thing the administrator will notice is that the media state for the DirectAccess client’s IP-HTTPS tunnel adapter interface is shown as disconnected.
In addition, the Get-NetIPHttpsState PowerShell command returns an error code 0x800b0101 indicating Failed to connect to the IP-HTTPS server; waiting to reconnect.
Err.exe translates this error to CERT_E_EXPIRED, indicating that the SSL certificate is no longer valid.
Viewing the IP-HTTPS SSL certificate is not possible using a web browser. Instead, use Nmap and the ssl-cert script to view the certificate.
nmap.exe -n -Pn -p443 [FQDN] –script ssl-cert
In the Operations Status window of the Remote Access Management console on the DirectAccess server, the IP-HTTPS status is listed as Critical. Details show IP-HTTPS not working properly, with an error stating the IP-HTTPS certificate is not valid, and clearly indicating that the certificate is expired.
The IP-HTTPS status can also be viewed at the command line by issuing the following command in an elevated PowerShell command window.
Simply renewing the SSL certificate is not sufficient to restore IP-HTTPS connectivity for remote DirectAccess clients. The DirectAccess configuration must also be updated to use the new certificate. In the Remote Access Management console, highlight DirectAccess and VPN under Configuration and then click Edit on Step 2 (for load-balanced or multisite DirectAccess deployments, first highlight the individual server and then click Configure Server Settings).Click Network Adapters, click Browse, and then select the new SSL certificate.
Click Ok, Next, and then Finish twice and Apply. Repeat these steps for each server in the load-balanced cluster, and for all servers in all entry points in the enterprise.
Alternatively, the IP-HTTPS certificate can be updated in the DirectAccess configuration by opening an elevated PowerShell command window and entering the following commands.
Important Note: Be sure to execute these commands on each DirectAccess server in the load-balanced cluster, and for all servers in all entry points in the enterprise.
Self-Signed Certificates
When DirectAccess is deployed using the Getting Started Wizard (GSW), also known as a “simplified deployment“, a self-signed certificate is used for IP-HTTPS. By default, this certificate expires 5 years after it is created. The expiration of a self-signed certificate presentsa unique challenge. Although the self-signed certificate can’t be renewed, it can be re-created or cloned using the New-SelfSignedCertificate PowerShell command. However, DirectAccess clients will not trust this new certificate until they receive the updated client settings via group policy. DirectAccess clients outside the network will not be able to establish IP-HTTPS connections until they receive these new policies. When they attempt to connect to the DirectAccess server without first updating group policy, the IP-HTTPS status will indicate an error code 0x800b0109 which translates to CERT_E_UNTRUSTEDROOT.
If the expired self-signed certificate is replaced with another self-signed certificate (not recommended), DirectAccess clients will have to come back to the internal network or connect remotely via client-based VPN to update group policy and receive the new DirectAccess client settings. A better alternative is to replace the expired self-signed certificate with a public SSL certificate that matches the existing public hostname. This will allow remote clients to reestablish DirectAccess connectivity without the need to udpate group policy first.
Summary
Certificate expiration must be monitored closely to ensure the highest level of availability for the DirectAccess remote access solution. Certificate auto enrollment can be leveraged to ensure that IPsec certificates are automatically renewed prior to expiration. However, the IP-HTTPS certificate must be renewed manually and requires additional configuration after it has been updated.