The January 2022 security updates for Microsoft Windows include several important updates that will affect Always On VPN deployments. Specifically, CVE-2022-21849 addresses a Remote Code Execution (RCE) vulnerability that should be addressed immediately. The January 2022 security update also includes updates for several IKE Denial-of-Service (DoS) vulnerabilities, in addition to privilege escalation vulnerabilities in the Remote Access Connection Manager.
Update – January 17, 2022: Microsoft has released out-of-band updates to address the issues with IPsec (IKEv2 and L2TP) when using non-Microsoft VPN devices. Updates can be found here.
Update – January 13, 2022: There have been numerous reports of this update breaking VPN functionality when using non-Microsoft VPN devices. If you are using Windows Server and RRAS you can safely update. If you are using a third-party device, you may encounter problems. In addition, there have been reports of issues with domain controllers and Hyper-V servers after installing this update. Please proceed carefully and be sure to have a backup before updating!
Vulnerable Systems
These vulnerabilities are present on both Windows Server and Client operating systems. Essentially, any Windows server or client using IPsec is vulnerable and potentially exploitable.
Vulnerabilities
The following is a list of security updates related to Always On VPN deployments.
Windows IKE Extension Remote Code Execution (RCE) Vulnerability
Secure Socket Tunneling Protocol (SSTP) is a Microsoft-proprietary VPN protocol with several advantages over Internet Key Exchange version 2 (IKEv2) for Always On VPN user tunnel connections. SSTP uses HTTP with Transport Layer Security (TLS) to encrypt communication between the Always On VPN client and the VPN gateway. SSTP is very firewall-friendly, with VPN connections operating on the commonly open TCP port 443, resulting in more consistent VPN availability. SSTP throughput is better compared to IKEv2 as well.
Learn more about TLS with Practical TLS, a comprehensive online video training course.
TLS and Windows Server
For versions of Windows Server before Windows Server 2022, the out-of-the-box security for TLS is not ideal. TLS is notoriously complex to configure, with myriad options for administrators to choose from. However, with the release of Windows Server 2022 and Windows 11, Microsoft has introduced support for the latest TLS specification, TLS 1.3, which eases much of this configuration pain.
TLS 1.3
TLS 1.3 provides significant advantages for Always On VPN SSTP user tunnel connections in security and performance.
Security
TLS 1.3 is greatly simplified and offers only five cipher suites, all considered secure by today’s standards. In addition, all TLS 1.3 ciphers support forward secrecy, ensuring the privacy of communication even in the event of a server private key compromise.
Performance
The TLS handshake in TLS 1.3 is streamlined and requires less back-and-forth (round trips) to establish a connection. TLS 1.3 speeds connection establishment for new Always On VPN user tunnel connections.
Caveat
Adding support for TLS 1.3 on the server-side is a compelling reason to consider upgrading existing Windows Server Routing and Remote Access Service (RRAS) servers to Windows Server 2022. However, TLS 1.3 support for SSTP also requires Windows 11 on the client-side. TLS 1.3 is not currently supported in Windows 10.
Summary
Realizing the performance benefits provided by TLS 1.3 will likely only occur in large environments supporting many thousands of concurrent connections per server. However, the security benefits apply to all deployments, regardless of size. Administrators should consider upgrading to Windows Server 2022 before proceeding with Windows 11 adoption.
As a follow-up to my last post regarding Always On VPN error 13801, this post will cover a similar and related error administrators may encounter, the 13806 error. As mentioned previously, certificate configuration is crucial for Always On VPN deployments. I described some specific certificates requirements for IKEv2 in this earlier post. Following this guidance, administrators should have no issues with IKEv2 Always On VPN connections. However, it is always possible to encounter an error if any of these certificates are missing or misconfigured.
Error 13806
Much like the error 13801 described previously, 13806 is also common. When an Always On VPN connection using IKEv2 fails, the Windows Application event log will record an 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 13806”.
IKE Failed To Find Valid Machine Certificate
Error 13806 translates to ERROR_IPSEC_IKE_NO_CERT, indicating IKE failed to find a valid machine certificate. The problem can be on the device, the VPN server, or an issue with the VPN server configuration.
Device Certificate
For the device tunnel, the most obvious cause of this error is a missing device authentication certificate on the client itself. Ensure the endpoint has a valid certificate issued by the organization’s internal PKI that includes Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2). The certificate must have a subject name matching the device’s FQDN. It must also be valid (not expired), trusted, and not revoked.
Certificate Chain
A 13806 error will occur if the device certificate installed on the client is not trusted or if the client does not trust the certificate installed on the VPN server. Ensure the client has all the necessary root and intermediate certification authority (CA) certificates installed in their respective certificate stores.
VPN Server Certificate
A 13806 error can also occur if the VPN server does not have a properly configured server certificate. Ensure the VPN server has a valid certificate issued by the organization’s internal PKI that includes both the Server Authentication (OID 1.3.6.1.5.5.7.3.1) and IP security IKE intermediate (OID 1.3.6.1.5.5.8.2.2) EKUs. The subject name must match the public fully qualified domain name (FQDN) used by VPN clients to connect to the VPN server (not the server’s NetBIOS name). Again, ensure the certificate is valid (not expired), trusted, not revoked, and all necessary root and intermediate CA certificates are installed in their respective certificate stores.
Certificate Revocation
An expired Certificate Revocation List (CRL) can also result in a 13806 error. Open the Enterprise PKI console (pkiview.msc) on an issuing CA and review the status of all CRLs. If any are expired, resolve any issues preventing the CRL from publishing successfully, then issue a new CRL by running certutil.exe -crl on the issuing CA server.
RRAS Configuration
Another cause of the 13806 error for the user tunnel is a misconfigured Routing and Remote Access Service (RRAS) VPN server. An error 13806 can happen if the administrator incorrectly defines a trusted root CA using Set-VpnAuthProtocol. Ensure that the root certificate thumbprint matches exactly the root CA server’s thumbprint used to issue certificates to VPN devices and the VPN server.
Get-VpnAuthProtocol
Root CA Certificate Thumbprint
Resolution
Ensure that devices and VPN servers have correctly configured certificates installed. If the root CA certificate is assigned incorrectly on the VPN server, follow the guidelines detailed here to update the configuration.
