Microsoft released the September 2026 security updates today, which include numerous fixes affecting Always On VPN deployments. This month’s edition addresses vulnerabilities in Windows Server Routing and Remote Access (RRAS), VPN protocols such as Secure Socket Tunneling Protocol (SSTP) and Internet Key Exchange version 2 (IKEv2). The updates also include Active Directory Certificate Services (AD CS), a crucial supporting infrastructure service for Always On VPN.
RRAS
September 2026 Microsoft security updates include 8 CVEs for RRAS. Four are rated Critical, the most severe having a CVSS rating of 9.8.
RCEs
The following four CVEs are Remote Code Execution vulnerabilities. All are rated critical.
Microsoft AD CS is commonly deployed to issue and manage certificates used for encryption and user and device authentication in Always On VPN deployments. The following four CVEs address vulnerabilities disclosed in AD CS. The first two are privilege escalation vulnerabilities, the third covers information disclosure, and the last addresses a tampering vulnerability. All are rated Important.
The September 2026 Microsoft security updates address several critical vulnerabilities affecting organizations that have deployed Microsoft Always On VPN. Administrators are encouraged to update their systems as soon as possible.
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.
The predominant solution for secure remote access today in the Microsoft ecosystem is Always On VPN. Always On VPN is based on traditional Virtual Private Network (VPN) technology originally developed in the mid-1990s. However, Microsoft recently introduced Entra Private Access, which is part of the Global Secure Access (GSA) Security Service Edge (SSE). Entra Private Access is an identity-centric Zero Trust Network Access (ZTNA) solution designed to replace traditional VPN solutions. It offers significantly improved security with granular resource access without dependency on on-premises infrastructure. This article outlines where each solution fits best and how organizations can transition safely between them.
Always On VPN
First introduced in Windows 8, Microsoft Always On VPN provides seamless, transparent, secure remote access using client-based VPN protocols such as Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP). When establishing a VPN connection, a virtual network adapter is created, and an IP address is assigned to the interface to facilitate tunneled network communication with the internal network.
Architecture
Always On VPN requires substantial on-premises supporting infrastructure. In addition to the VPN servers themselves, administrators must also deploy authentication servers (RADIUS or NPS) and certificate services (AD CS). Administrators must manage public TLS certificates for SSTP connections. Also, larger deployments may require on-premises load balancers and/or cloud-based Global Server Load Balancing (GSLB) solutions. Further, additional configuration is needed to integrate Entra ID Conditional Access. Because this infrastructure must be publicly accessible by design, it becomes an attractive target for attackers. In addition, the complex infrastructure has many interdependencies, resulting in significant administrative overhead for network and security administrators.
Access Model
Most commonly, Always On VPN provides full network access to the internal network. Full network access is accomplished by configuring IP routing on the client to ensure internal client network subnets are routed over the VPN tunnel. In this model, clients are often implicitly trusted once connected. Once authenticated and authorized, users receive full, unfettered access to the internal network across all protocols and ports. This level of access introduces a significant security risk and does not adhere to modern zero-trust network access models. To address this, administrators must implement additional security controls internally (perimeter or DMZ firewalls) to restrict network access for Always On VPN clients.
Zero Trust Always On VPN?
Always On VPN includes support for traffic filters that can restrict network access and provide zero-trust-like access. However, these controls exist only on the client side, so an attacker with administrative access to the endpoint can easily bypass them. They should not be considered a reliable way to enforce zero trust for Always On VPN connections.
Entra Private Access
Entra Private Access is part of Microsoft’s Global Secure Access (GSA) Security Service Edge (SSE). It is a robust, cloud-based zero-trust network access (ZTNA) service that provides granular access to on-premises resources. It requires installing a client-side agent and one or more Private Network connectors on-premises to facilitate remote network access. Entra Private Access deeply integrates with Entra ID, so you can easily configure Conditional Access policies for any published resource, including multifactor authentication for legacy protocols such as SSH.
Limited Network Access
Unlike legacy VPNs, GSA does not create a virtual network interface when establishing a connection. Instead, GSA operates as a filter driver deep in the Windows networking stack, intercepting and rerouting network traffic bound for the internal network. The GSA client eliminates the complexities of IP address management, network routing, and firewalling. In addition, authentication and authorization are handled natively by Entra ID and Conditional Access.
Minimal Infrastructure
Entra Private Access is a cloud-based service with minimal on-premises supporting infrastructure requirements. Administrators must only deploy the Entra Private Network connector on one or more on-premises servers to facilitate remote access for Global Secure Access clients. The Entra Private Network is a lightweight software agent that requires little to no post-deployment support. The administrative burden is much lighter compared to Always On VPN.
Key Differences at a Glance
The table below highlights the most important architectural, security, and operational differences to help determine which solution best fits your environment.
Aspect
Always On VPN
Entra Private Access
Architecture
On-premises VPN gateway(s)
Cloud-based service
Access Model
Full network access via a routable IP address assigned to the endpoint
Per-resource zero-trust network access (ZTNA); no full network access
Authentication
On-premises AD or Entra ID (AD-synced accounts only)
Entra Private Network connector (minimum one server, two recommended for redundancy)
Device Support
Windows only
Cross-platform (Windows, macOS, iOS, Android)
Licensing
Included in OS license
Additional per-user costs with Entra Suite or standalone Entra Private Access license
Advantages of Always On VPN for Domain-Joined Endpoints
Always On VPN integrates more naturally with classic Active Directory domain-joined Windows devices. Always On VPN includes features that Entra Private Access does not currently provide, which administrators may require to provide full support for their mobile devices.
Device Tunnel Support
The Always On VPN device tunnel provides machine-based pre-logon connectivity. The device tunnel ensures access to on-premises authentication services (domain controllers) before the user logs on to the endpoint. The device tunnel allows for logging in without cached credentials (e.g., for new users) and streamlines password changes. In addition, it ensures network access to support complete group policy processing for remote users. Entra Private Access is user-based only and does not include device-based connectivity. The device tunnel is one of the most significant functional gaps between Always On VPN and Entra Private Access.
Note: Although device-based connections are not currently available in Entra Private Access at the time of this writing, Microsoft may add the feature in the future.
Windows Native Integration
Always On VPN leverages the built-in Windows VPN client, which integrates deeply with the operating system. The Windows VPN client is mature and robust, supporting secure authentication protocols with certificates or smart cards. Always On VPN requires no additional client software. For Entra Private Access, administrators must deploy and manage a separate software component, the Global Secure Access client.
Full Network Access
The domain is a trust boundary, and domain-joined endpoints require broad network access to function. For example, domain-joined endpoints must have access to domain controllers, and most access those resources using several protocols and numerous different ports. In addition, these endpoints must be able to connect to a variety of other internal resources, such as DNS servers, certification authorities (CAs), revocation servers (HTTP, OCSP, LDAP), systems management servers, file shares, printers, and more. Furthermore, much of this access occurs via Remote Procedure Call (RPC) and Distributed COM (DCOM), which use ephemeral (dynamic) port ranges (49152-65535). Enforcing firewall policy to restrict access for remote domain-joined clients is challenging because these endpoints require significant resources.
So, if your managed endpoints are primarily domain-joined and depend on pre-logon network connectivity, Always On VPN remains the more mature and feature-complete choice today.
Why Entra Private Access is Ideal for Native Entra ID Joined Devices
Entra Private Access is designed around a cloud-first, identity-centric Zero Trust model and has explicit client and device requirements that align best with Entra ID joined devices.
Client Requirements
The Global Secure Access client required for Entra Private Access requires Windows devices to be Microsoft Entra-joined or Microsoft Entra hybrid-joined. Domain-joined only (non-hybrid) devices are not supported. Unlike the native VPN client built into Windows, the Global Secure Access client is a separate piece of software that administrators must install independently.
Per-App Zero Trust
Entra Private Access controls access using FQDNs or IPs (individual, ranges, or networks) and specific protocol/port combinations instead of full network routing. Per-app access aligns with the modern cloud-native device model by avoiding broad network exposure and evaluating every access request through Conditional Access (including device compliance, MFA for legacy protocols, and more). Unlike Always On VPN, the principle of least privilege is enforced at all times.
Simplified Management
Entra Private Access requires minimal on-premises supporting infrastructure. There’s no need for VPN servers, RADIUS servers, or complicated certificate services for VPN authentication. Entra Private Access natively uses Entra ID and Conditional Access, eliminating the need for certificate authentication.
Cross Platform
Entra Private Access provides cross-platform support. Not only does it support Windows clients (Enterprise or Professional editions), but it also supports macOS, iOS, and Android. Broad client support makes Entra Private Access a comprehensive, secure remote access solution for all your managed endpoints.
In summary, Entra Private Access provides a cleaner, more secure, and lower-management experience for organizations moving toward Entra ID joined device fleets, especially when combined with Microsoft Intune for management and Conditional Access policies for enhanced security.
Licensing
Always On VPN and Entra Private Access use different licensing models.
Always On VPN
No per-user or per-device licensing required for Always On VPN. Always On VPN licensing is included with the Windows operating system license you already own.
Entra Private Access
Entra Private Access requires a separate license and incurs an additional per-user cost. It is included with the Microsoft Entra Suite license (~$12.00/user/month), or as a separate, standalone Entra Private Access license (~$5.00/user/month). You can learn more about Microsoft Entra licensing here.
Migration Path
Migrating from Always On VPN to Entra Private Access is low-risk. Using a phased approach, administrators can move from Always On VPN to Entra Private Access with minimal disruption. Start by planning for Entra Private Access (client agent deployment, connector placement, conditional access policies, etc.), then gradually deploy the solution, initially coexisting with Always On VPN but moving toward full deployment. Once complete, decommission the legacy VPN. Key steps include:
Assess your resources, devices, and Entra ID licensing.
Enable Entra Private Access, deploy one or two Private Network Connectors on-premises, and install the Global Secure Access client on devices.
Configure access rules. Begin with Quick Access to replicate VPN-like behavior.
Run both solutions side-by-side. Pilot with a small group, migrate apps/users incrementally, and enforce Conditional Access (including MFA for sensitive applications).
Phase out and decommission Always On VPN once stable.
This approach reduces infrastructure overhead, delivers granular zero trust security, and aligns with a cloud-first identity strategy.
Summary
Microsoft Always On VPN provides reliable on-premises remote access for Windows devices using protocols such as IKEv2 and SSTP. Today, it remains the best choice for environments that use traditional Active Directory domain-joined devices, where pre-logon connectivity and broad network access are required. However, Always On VPN requires heavy infrastructure and typically grants risky full network access.
Entra Private Access is the preferred solution for organizations adopting a cloud-first, Zero Trust strategy with Entra ID joined endpoints. Its per-application access model, native Conditional Access enforcement, reduced infrastructure footprint, and cross-platform support make it ideal for modern managed endpoints where least-privilege access and simplified operations are priorities.
In practice, many organizations will benefit from running both solutions in parallel during a transition period, using Always On VPN to support domain-joined endpoints and Entra Private Access for modern, Entra-joined devices. Over time, as device fleets and applications modernize, Entra Private Access can progressively replace legacy VPN infrastructure while improving security posture and reducing operational complexity.
Ready to Modernize Your Remote Access Strategy?
Schedule a free one-hour consultation to review your current Always On VPN deployment, assess readiness for Entra Private Access, and identify a secure, practical migration path tailored to your environment. We’ll cover architecture considerations, device requirements, licensing implications, and common pitfalls—no obligation required. Fill out the form below to request more information and schedule your free consultation.
The Azure VPN gateway has been an option for supporting Microsoft Always On VPN client connections for organizations moving resources to the cloud. Today, Azure VPN gateway supports Internet Key Exchange version 2 (IKEv2), OpenVPN, and Secure Socket Tunneling Protocol (SSTP), although SSTP support has long been limited in scope and scalability. However, Microsoft recently indicated that some important changes are coming soon that will affect VPN protocol support on the Azure VPN gateway.
SSTP and Azure VPN Gateway
Microsoft has announced plans to deprecate and eventually remove support for SSTP on the Azure VPN gateway.
Key Dates
Here is Microsoft’s timeline for retiring SSTP for VPN connections.
March 31, 2026 – SSTP can no longer be enabled on new or existing gateways
March 31, 2027 – Existing SSTP connections will stop functioning
SSTP: Second Class Citizen
The retirement of SSTP for Azure VPN gateway should not have a significant impact on Always On VPN deployments. Support for SSTP on Azure VPN gateway has always been limited, making it a less viable option for most Always On VPN deployments. SSTP connections are capped at 128 concurrent connections (256 in active-active mode), regardless of gateway SKU. Additionally, Azure VPN gateway does not support simultaneous user and device tunnels, further limiting its usefulness in modern Always On VPN designs.
Plan Migration Now
If you are using Azure VPN gateway to support Always On VPN client connections, now is the time to begin planning a migration to IKEv2, which offers better scalability and native Always On VPN support. Alternatively, consider Windows Server RRAS in Azure, a third-party VPN solution, or Entra Private Access if Azure VPN gateway no longer meets your requirements.
More Information
For official guidance, see SSTP Protocol Retirement and Connections Migration. If you’re unsure how this change affects your Always On VPN deployment, or you would like help planning a migration, this is a good time to review your design and roadmap. Fill out the form below, and I’ll provide you with more information.
Always On VPN error 13801 is common when establishing an IKEv2 VPN connection. Typically, the issue is related to a configuration error or a problem with certificate deployment. However, administrators may encounter the 13801, an IKE authentication error, intermittently. Configuration errors are binary. If there is a misconfiguration, IKEv2 never works at all. However, a configuration error seems unlikely since the connection works occasionally yet fails at other times.
Client Authentication
The minimum application policy (Enhanced Key Usage, or EKU) requirement for the device authentication certificate for IKEv2 is Client Authentication (1.3.6.1.5.5.7.3.2). When intermittent 13801 errors occur, administrators may find multiple certificates in the local computer certificate store with the Client Authentication EKU issued by different certificate authorities. Commonly, Intune-managed Windows devices may include several certificates with Client Authentication.
Certificate Selection
When Windows attempts to establish an Always On VPN IKEv2 connection, and there are multiple certificates in the local computer certificate with Client Authentication defined, Windows must choose one certificate to use for the connection. If Windows chooses incorrectly, you will receive the 13801 IKE authentication failure error. If Windows selects the right one, the connection succeeds.
Resolution
There are several ways to resolve this issue. The best way is to update the Always On VPN device authentication certificate to include the IP security IKE intermediate application policy (EKU). When Windows encounters multiple client authentication certificates in the local computer certificate store, it will prefer any certificate with the IP security IKE intermediate application policy for IKEv2 VPN connections. Including the IP security IKE intermediate application policy on the Always On VPN device authentication certificate ensures proper certificate selection when multiple client authentication certificates are present.
Note: This change must be made to the Intune certificate enrollment template when using Intune with PKCS or SCEP.
Certificate Template
To update an existing Always On VPN device authentication certificate to include the IP security IKE intermediate application policy, open the certificate templates management console (certtmpl.msc) and perform the following steps.
Right-click the VPN device authentication certificate template and choose Properties.
Select the Extensions tab.
Click on Application Policies.
Click Edit.
Click Add.
Select the IP security IKE intermediate application policy.
Click Ok.
Click Ok.
Click Ok.
Once complete, any certificates issued after this change is applied will now include the IP security Ike intermediate application policy.
Force Renewal
Administrators may wish to update all certificates immediately rather than wait until they renew to receive the new setting. The course of action depends on how certificates are issued.
On-Premises
When issuing certificates using Active Directory Certificate Services (AD CS) on-premises, right-click the Always On VPN device authentication certificate template and choose Reenroll All Certificate Holders. This will force all domain-joined clients with Autoenroll permissions on the template to renew their certificate on their next enrollment cycle, regardless of the certificate’s lifetime.
Intune
Follow the steps below to force re-enrollment for all certificate holders when deploying certificates using Intune.
SCEP – Add the IP Security IKE Intermediate application policy to the Intune VPN policy. After this change is applied, Intune will reenroll all endpoints.
PKCS– A new Intune device configuration policy must be created that includes the IP security IKE intermediate application policy. Assign the new policy and remove the old one to replace all certificates.
PowerShell
It’s also possible to resolve this issue using PowerShell. Administrators can use the Set-VpnConnection PowerShell cmdlet to select a certificate based on the root certification authority (CA) or a specific custom application policy defined on the Always On VPN device authentication certificate. Be sure to add the -AllUserConnection switch when working with the device tunnel.
Root CA
Open a PowerShell command window and run the following command.
$RootCA = Get-Child-Item -Path Cert:\LocalMachine\My\<thumbprint of root CA certificate> Set-VpnConnection -Name <name of VPN profile> -MachineCertificateIssuerFilter $RootCA
Application Policy
Open a PowerShell command window and run the following command.
Set-VpnConnection -Name <name of VPN profile> -MachineCertificateEKUFilter <OID>
Note: When using a custom application policy Windows will return a warning message stating the EKU could not be validated. You can safely disregard this warning.
Intune Remediation
While running PowerShell commands locally might be helpful for troubleshooting and targeted evaluation testing, deploying settings via PowerShell at scale is challenging. For those organizations managing their devices using Microsoft Intune, I’ve published a few detection and remediation scripts on GitHub to perform these tasks.
The intermittent Always On VPN 13801 IKE authentication credentials are unacceptable error message is best resolved by updating the Always On VPN device authentication certificate to include the IP security IKE intermediate application policy (EKU). Although using PowerShell also works, it doesn’t scale effectively. SCCM or Intune remediations can help, but I’d encourage you to update the certificate template as best practice instead.
Organizations migrating on-premises applications, data, and infrastructure to the cloud may also consider terminating Always On VPN connections there. Using one of the native Azure VPN services might be compelling at first glance. After all, having an Azure-managed VPN gateway service sounds intuitive. However, some severe limitations exist for using Azure VPN services for Always On VPN deployments.
Azure VPN Gateway
The following are limitations for Always On VPN with Azure VPN gateway.
Authentication Methods
Azure VPN gateway supports both EAP and machine certificate authentication. However, it can only support one authentication method at a time. With only EAP or certificate authentication, administrators must choose between a device or user tunnel. A single Azure VPN gateway cannot support both at the same time. For native Entra ID joined devices, this is not a problem. However, for native on-premises Active Directory or hybrid Entra ID joined devices, this is a problem, as the device tunnel is essential in these scenarios.
Note: Technically speaking, administrators could deploy another Azure VPN gateway to work around this limitation. However, Azure limits VPN gateway deployments to one per virtual network. This requires administrators to deploy a second VPN gateway in a separate virtual network, which then requires virtual network peering to be enabled, complicating the configuration greatly.
SSTP
Although the Azure VPN gateway supports SSTP, it is, unfortunately, a second-class citizen. Today, all SKUs of the Azure VPN gateway are limited to just 128 SSTP connections (256 in active/active mode). There is currently no way to increase this. If more than 256 connections are required, you must use IKEv2.
RADIUS
In addition, there is currently no option to change the default timeout value (30 seconds) for RADIUS authentication requests. This short timeout value presents a challenge when using MFA with the NPS extension or with Azure Conditional Access, as users may be unable to respond to the push notification before the timeout expires, resulting in failed authentication attempts.
Geographic redundancy using Azure Traffic Manager (or another global server load balancer) with two or more gateways is not supported when using the Azure VPN gateway. Azure manages the certificate used on the gateway, which includes a certificate with the subject name of the individual gateway. There is no option to supply a custom certificate with a global hostname in the subject, which is required to support geographic redundancy. With that, administrators are limited to the redundancy provided natively by the Azure VPN gateway.
IPv6
Azure does not support Azure VPN gateway in a virtual network that includes IPv6 addressing.
Azure Virtual WAN
Azure Virtual WAN includes many of the same limitations as the Azure VPN gateway, in addition to the following.
SSTP
Unlike the Azure VPN gateway, there is no support for SSTP in Azure Virtual WAN.
IPv6
IPv6 is not currently supported at all in Azure Virtual WAN.
Summary
Intuitively, it seems that leveraging native Azure VPN gateway services would be ideal. However, due to the limitations outlined in this article, administrators must decide carefully if any of these prevent adoption in their environment. Although not formally supported, many organizations deploy Windows Server Routing and Remote Access (RRAS) servers in Azure to address these limitations.
Once again, it’s time to patch! After several quiet months, there are a few crucial updates Always On VPN administrators will want to get deployed soon. Thankfully, the impact of the security updates related to Always On VPN is low this time, as there is only one Remote Code Execution (RCE) vulnerability, and it’s for a legacy protocol that should be in limited use today.
IKEv2
CVE-2023-36726 addresses a security vulnerability in Windows Internet Key Exchange (IKE) that can lead to privilege escalation. An attacker who successfully exploits this vulnerability can elevate privileges to that of the local SYSTEM.
L2TP
This month’s update discloses several Layer Two Tunneling Protocol (L2TP) vulnerabilities. The following CVEs all address a vulnerability where an attacker can send a specially crafted protocol message to a Windows Routing and Remote Access Service (RRAS) server, which could lead to remote code execution on the server.
The impact of the L2TP security vulnerabilities should be minimal in most organizations. L2TP is a legacy VPN protocol not commonly used for Always On VPN. However, misconfiguration can leave vulnerable RRAS servers exposed. Administrators must ensure that inbound UDP port 1723 is not open from the Internet. In addition, L2TP should be disabled on the RRAS server if not in use. See the article on the May 2023 security updates for details.
Always On VPN supports a variety of VPN protocols for the user tunnel. Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP) are the most common. I wrote about the advantages and disadvantages of each in this post. To summarize, IKEv2 provides the highest security options but suffers from operational limitations. SSTP offers excellent security and is generally more reliable.
VpnStrategy
Always On VPN administrators must choose between IKEv2 and SSTP when configuring the Always On VPN user tunnel. Some administrators may prefer to use IKEv2 when available but then fall back to SSTP if it is not. To accomplish this requires editing the rasphone.pbk file and setting the value of VpnStrategy to 8, as described here.
Challenges
Unfortunately, setting the VpnStrategy value to 8 poses some challenges. Updating rasphone.pbk requires editing a text file on each endpoint post-deployment. Updating rasphone.pbk can be automated using the Update-Rasphone.ps1 script or Microsoft Intune proactive remediation.
Limitations
By default, Windows will overwrite the VpnStrategy setting in rasphone.pbk when fallback occurs. For example, setting VpnStrategy to prefer IKEv2 over SSTP will be reset to use SSTP first if a connection with IKEv2 fails. There’s a registry setting available that’s supposed to prevent this, but it doesn’t always work as expected.
Windows 11
There’s good news for administrators deploying Always On VPN on Windows 11. Microsoft recently introduced support for additional NativeProtocol types in XML. Specifically, VPN protocol preference can now be defined using the ProtocolList native protocol type. When using the ProtocolList native protocol type, each supported VPN protocol is listed in order of preference using the syntax shown below.
In addition, the RetryTimeInHours value defines the time Windows will try the last successful connection protocol. Setting this value to 0 overrides this and ensures the preferred protocol (the first protocol in the list) will always be attempted first.
SSTP Only
Previously the VPNv2CSP only supported IKEv2 or Automatic as values for the native protocol type. Windows 11 now supports SSTP as a native protocol type. Administrators configuring Always On VPN user tunnel connections using SSTP exclusively can now use this option.
Caveats
While the settings above are supported in both Windows 11 21H2 and 22H2, there are some known issues when enabling these settings. Specifically, when administrators define the ProtocolList value for the native protocol type, IKEv2 is always shown as the active protocol, even when an SSTP connection is established.
Also, if ProtocolList is used, the VPN connection cannot be managed using PowerShell. The VPN profile will not be displayed when running Get-VpnConnection at the time of this writing. Hopefully Microsoft will fix this soon.
Hey, Always On VPN administrators! It’s the second Tuesday of the month, which means security updates for Windows have been released. This month’s batch includes an update to address a critical vulnerability likely to affect many Always On VPN implementations using Windows Server.
SSTP Vulnerability
CVE-2023-24903 documents a vulnerability on Windows Servers with the Routing and Remote Access Service (RRAS) configured to support Secure Socket Tunneling Protocol (SSTP) for VPN connections. This is a remote code execution (RCE) vulnerability that can be exploited when an attacker sends a specifically crafted malicious packet to the server. Administrators are encouraged to update as soon as possible.
Mitigation
SSTP is commonly used for Always On VPN user tunnels. However, if administrators have configured user tunnels using IKEv2, or are using the device tunnel only, consider blocking inbound TCP 443 at the edge firewall to prevent attacks from the Internet. In addition, if SSTP is not in use, consider disabling support for SSTP by opening an elevated PowerShell command window and running the following commands.
Always On VPN administrators may be familiar with an issue that affects Windows Server Routing and Remote Access Service (RRAS) servers, where many stale VPN connections appear in the list of active connections. The issue is most prevalent when using IKEv2, either for the Always On VPN device tunnel or the user tunnel. Typically, this does not cause problems, but some administrators have reported issues related to port exhaustion or failed IKEv2 connections when many stale connections are present. Stale connections happen so frequently that I created a PowerShell script to clean them up on the RRAS server. Restarting the RemoteAccess service or rebooting the server also clears stale connections.
Microsoft Fix
Thankfully, Microsoft has addressed these issues in Windows Server 2019 and Windows Server 2022 this month. An update is now available in the March 2023 security update that resolves this problem.
You can find more information about the updates here.
The update was not made available for Windows Server 2016, however. Organizations are encouraged to upgrade to Windows Server 2019 or later to address this problem.
