All posts tagged Routing and Remote Access

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.

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

Additional Information

Microsoft Security Updates for April 2026

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

1 Comment

by Richard M. Hicks on April 14, 2026 • Permalink

Tagged device tunnel, IKE, IKEv2, Microsoft, Patch Tuesday, RAS, RCE, remote code execution, Routing and Remote Access, RRAS, user tunnel, vulnerability, Windows

Posted by Richard M. Hicks on April 14, 2026

https://directaccess.richardhicks.com/2026/04/14/always-on-vpn-ikev2-security-vulnerability-april-2026/

Always On VPN RRAS and PowerShell 7

PowerShell is an essential tool for administrators supporting Microsoft Always On VPN. It is critical for configuring supporting infrastructure services, such as Routing and Remote Access (RRAS) and Network Policy Server (NPS), as well as provisioning and managing Always On VPN client configuration settings on endpoints. The current version of PowerShell, PowerShell 7.5.3, is a game-changer for scripting and automation, bringing a host of improvements over its predecessors. PowerShell 7 offers better performance, lower memory usage, and cross-platform support (Windows, macOS, and Linux), making it more versatile than ever.

Problem in PowerShell 7

Recently, I discovered an oddity with PowerShell 7 when reviewing the configuration of an RRAS server. Specifically, PowerShell 7 differs in the way it produces output for the Get-RemoteAccess command, preventing administrators from viewing the details of the currently configured TLS certificate used for SSTP VPN connections in RRAS.

PowerShell 5

Running Get-RemoteAccess in PowerShell 5 provides detailed information about the SslCertificate property in the output of the command, as shown here.

Note that the data returned in the SslCertificate property is of the type X509Certificate2.

PowerShell 7

In PowerShell 7, Get-RemoteAccess displays only a string of numbers instead of detailed certificate information.

Notably, the data returned in the SslCertificate property is of the type System.Byte.

Solution

While PowerShell 7 doesn’t output the certificate details in human-readable form, you can easily convert the data using the following PowerShell command.

[System.Security.Cryptography.X509Certificates.X509Certificate2]::new((Get-RemoteAccess).SslCertificate) | Format-List

AovpnTools Module

To simplify administration, I’ve added a function to my AovpnTools PowerShell module called Get-VpnServerTlsCertificate. This function allows you to view the currently configured SSTP certificate details directly with a single command. In addition, you have the option to save the certificate to a file for further inspection and troubleshooting.

The GetVpnServerTlsCertificate function is included in AovpnTools v1.9.8 and later. You can install AovpnTools from the PowerShell gallery by running the following command.

Install-Module -Name AovpnTools

You can also find the AovpnTools PowerShell module on GitHub.

Summary

With PowerShell 7, RRAS certificate details display differently, but administrators can quickly resolve this using a simple conversion or the Get-VpnServerTlsCertificate function in the AovpnTools module. Either way, administrators can continue to use PowerShell 7 to manage their Windows Server RRAS servers.