Always On VPN IKEv2 Security Vulnerability April 2026

Microsoft published its Security Updates for April 2026 today, and the good news is that there are no Windows Server Routing and Remote Access (RRAS) vulnerabilities this month. However, they disclosed a critical remote code execution (RCE) vulnerability that impacts deployments using Internet Key Exchange version 2 (IKEv2).

IKE Service Extensions RCE

CVE-2026-33824 addresses a security vulnerability in the Windows Internet Key Exchange (IKE) Service Extensions. This vulnerability is a Remote Code Execution (RCE) vulnerability, with a CVSS 3.1 base score of 9.8 (Critical). Always On VPN implementations that use the device tunnel or IKEv2 for the user tunnel are affected.

Impact

This vulnerability presents a unique challenge to Always On VPN administrators as IKEv2 is required to support device tunnel connections. Some implementations also use IKEv2 for the user tunnel. In either case, the vulnerable VPN server, often domain-joined, is reachable from the Internet, greatly increasing the attack surface and exposure to this vulnerability.

Recommendations

For deployments that use IKEv2 (device or user tunnel), administrators should update their RRAS server as soon as possible to protect against potential attacks on this service.

Not Using IKEv2?

If you are not using the device tunnel or IKEv2 for the user tunnel, ensure the following IKEv2 ports are blocked at the edge firewall.

  • Inbound UDP port 500 (IKE)
  • Inbound UDP port 4500 (IKE NAT-T)

In addition, consider disabling IKEv2 on the RRAS server by opening an elevated command window and running the following command.

netsh.exe ras set wanports device = "WAN Miniport (IKEv2)" rasinonly = disabled ddinout = disabled ddoutonly = disabled maxports = 0

Optionally, you can use the Routing and Remote Access management console (rrasmgnt.msc) to perform this task.

  1. Right-click on Ports and choose Properties.
  2. Select WAN Miniport (IKEv2).
  3. Click Configure.
  4. Uncheck Remote access connections (inbound only).
  5. Uncheck Demand-dial routing connection (inbound and outbound).
  6. Enter 0 in the Maximum ports field.
  7. Click Ok.

Additional Information

Microsoft Security Updates for April 2026

CVE-2026-33824 – Windows Internet Key Exchange (IKE) Service Extension RCE

Entra Private Access and VPN Migration Strategies on Entra.News

I recently had the opportunity to connect with Merill Fernando from Microsoft as a guest on his popular Entra.News podcast to discuss Microsoft Entra Private Access, which is part of the Entra Global Secure Access Security Service Edge (SSE) service. We spent the hour talking about the similarities and differences between classic VPN technologies and zero-trust network access (ZTNA). In addition, we discussed some technical aspects of Entra Private Access, and I shared migration and coexistence strategies to help ease the transition to zero trust. Also, we discussed the importance of integrating Entra Conditional Access and the shift from network to application access. You’ll find the interview at Entra.News and also on YouTube. Enjoy!

Additional Information

How to Migrate from Legacy VPN to Entra Private Access – Entra.News

Microsoft Entra Private Access

Always On VPN vs. Entra Private Access

Microsoft Entra Private Access Network Connector Overview and Deployment Strategies

Microsoft Entra Private Access Intelligent Local Access

DirectAccess IPHTTPS and Let’s Encrypt 6-Day Certificates

I’ve written extensively about how public TLS certificate lifetimes will drop to just 47 days by March 2029. Before then, we’ll see certificate lifetimes gradually drop from the current 398 days to 200 days on March 15, 2026, and then to 100 days on March 15, 2027. In preparation for this, I’ve been working with many customers to deploy automated certificate enrollment and renewal solutions to eliminate the need for manual intervention. Interestingly, Let’s Encrypt now offers extremely short-lived certificates that are good for just 6 days! While they work just fine for Always On VPN, I discovered they will not work for DirectAccess.

6-Day Certificate

After successfully enrolling for a 6-day TLS certificate from Let’s Encrypt (I used CertKit, BTW!), I encountered an error when trying to assign the short-lived certificate to the IP-HTTPS listener in the DirectAccess configuration. Specifically, when running the Set-RemoteAccess PowerShell command, I received the following error.

Set-RemoteAccess: The parameter is incorrect.

Further investigation showed that I could install other public TLS certificates just fine. For some reason, though, DirectAccess did not like this new 6-day certificate.

Missing Subject Name

After digging a bit deeper, I realized the Subject field of the new 6-day Let’s Encrypt certificate was empty.

Subject vs. SAN in Modern TLS

Modern TLS clients rely entirely on the Subject Alternative Name (SAN) field for identity validation, and the older practice of matching against the certificate’s Subject field has been phased out for many years. Many certificate authorities, including Let’s Encrypt, now leave the Subject field empty because it no longer serves a functional purpose in current TLS implementations. DirectAccess still expects this field to contain data and does not properly fall back to SAN‑only validation. As a result, any certificate with an empty Subject field, such as the new 6‑day certificates from Let’s Encrypt, will fail when applied to the DirectAccess IP‑HTTPS listener.

Workaround

Admittedly, using 6-Day public TLS certificates for DirectAccess is extreme and likely overkill for this workload. The good news is that DirectAccess still works perfectly with 90-day Let’s Encrypt certificates, so the lack of 6-day certificate support should not be impactful.

CertKit

Have you heard about CertKit? CertKit, an online service for automating Let’s Encrypt certificate enrollment and renewal, has added support for Always On VPN and DirectAccess. Find details on leveraging it for public TLS certificates for these solutions here.

Additional Information

Always On VPN SSTP with Let’s Encrypt Certificates

Always On VPN and 47-Day Public TLS Certificates

The Case for Short-Lived Certificates in Enterprise Environments

CertKit Agent Support for Always On VPN SSTP and DirectAccess IP-HTTPS TLS Certificates