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
Windows IKE Extension Denial of Service Vulnerabilities
Windows Remote Access Connection Manager Elevation of Privilege Vulnerability
Additional Information
A list of all fixes in the January 2022 security update, along with links to the updates themselves, can be found here.
Matt Wilkinson
/ January 13, 2022Not sure why there is a link to a Polar Bear on Youtube in the Acknowledgements for https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-21849 . I submitted feedback.
timbo01
/ January 18, 2022Very strange – doesn’t look like it’s the only time “Polar Bear” has been acknowledged either. I wonder what all that is about?
Andy Chips
/ January 13, 2022Just be aware that there appear to be major issues with this patch when applied to certain Domain Controllers and Hyper-V servers.
Richard M. Hicks
/ January 13, 2022Hearing those reports too. I’m only recommending that RRAS servers and Windows Always On VPN clients be updated at this point. 🙂
timbo01
/ January 18, 2022Microsoft have now released OOB emergency updates to fix the issues raised by certain users. I have seen IKEv2 Device Tunnels failing (terminating to Cisco ASA Endpoints not RRAS) after clients had applied the January patches. I hope the new “Optional Updates” fix these issues for us – we are about to test.
Richard M. Hicks
/ January 20, 2022Indeed, the issue affected only third-party (non-Microsoft) VPN devices. The recent security updates enforced a check of the Vendor ID field, but some vendors weren’t using this, causing IPsec connections (L2TP and IKEv2) to fail. I’ve updated the post to include links to the out-of-band updates to address these issues.
Fernando
/ January 13, 2022Thank you for the quick update on this. We’ve recently disabled IKEv2 device tunnel access to the VPN servers on our firewall and are only using SSTP. Until we patch, hoping this is enough to mitigate external threats.
David White
/ January 28, 2022Hi Richard.
We’ve just installed January 2022 updates and are now getting authentication errors affecting sysvol (GPO) and drive maps. Domain controller Security event log shows kerberos errors (event ID 4771) for affected users. Microsoft released an out-of-band update on Jan 17th which mentioned IKE/VPN issues – we installed this on both servers and clients but the error persists.
I found a July 2020 post on Twitter where some users tried modifying rasphone.pbk, setting UseRasCredentials=0 to get kerberos issues resolved. This works for us, although it’s not an ideal solution as we’d like to know what Microsoft have implemented. Have you seen this or have your contacts reported anything? Many thanks. Dave.
Richard M. Hicks
/ January 28, 2022That’s interesting. I know there were some issues with domain controllers being reported with the original update. However, I think those were catastrophic (blue screens) and not operational issues as you describe. Have you tried rolling back the updates to see if the issue resolves itself? It does appear something changed if setting UseRasCredentials to 0 solves your problem though.
David White
/ January 31, 2022Hi Richard. Thanks for replying. We’ve uninstalled both the OOB and January updates from the AOVPN servers and the domain controllers, but still get the error. Should the Network Policy Servers be rolled back too? We can connect to drive mappings with FQDN, but users are reporting other connectivity issues (we have a hybrid Azure domain, not sure if this is relevant). My colleague has a workaround which is to delete the certificate-based credential session in Credential Manager, but this resets itself when logging back on. Are there any further issues we need to be aware of setting UseRasCredentials to 0? Thank you.
Richard M. Hicks
/ January 31, 2022It’s possible that removing the update from the NPS server might help. I’d certainly try that. Another alternative to setting UseRasCredentials to 0 is to enable the following group policy on your domain.
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network access: Do not allow storage of passwords and credentials for network authentication
Let me know if that helps!
David White
/ February 1, 2022The day we patched our AOVPN servers and domain controllers, a CRL certificate expired. Note to anyone experiencing these issues, check your CRL cert first! Thanks for your help Richard.
Richard M. Hicks
/ February 1, 2022If it’s not DNS it’s CRLs! 😉