All posts tagged device tunnel

Always On VPN Security Updates November 2026

Always On VPN security updates

Microsoft released the November 2026 security updates today, which include three vulnerabilities affecting Always On VPN deployments. This month’s release addresses issues in the Secure Socket Tunneling Protocol (SSTP) and Internet Key Exchange (IKE). And for a change, there are NO vulnerabilities in the Windows Server Routing and Remote Access Service (RRAS) this month!

SSTP Vulnerabilities

SSTP is commonly used for Always On VPN user tunnel connections. Because SSTP is, by design, exposed directly to the Internet, vulnerabilities affecting this protocol deserve attention. This month’s updates address the following two SSTP vulnerabilities. Both are rated Important.

CVE-2026-105561 – Windows SSTP Denial of Service Vulnerability (CVSS 7.5)

CVE-2026-105510 – Windows SSTP Elevation of Privilege Vulnerability (CVSS 7.0)

IKE Vulnerability

The November 2026 security updates also address a spoofing vulnerability in the Windows IKE Extension. Always On VPN implementations that use the device tunnel or IKEv2 for the user tunnel are affected. Microsoft rates this vulnerability as Important.

CVE-2026-122169 – Windows IKE Extension Spoofing Vulnerability (CVSS 7.5)

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 entirely. Guidance for doing this is in my earlier post, Always On VPN IKEv2 Security Vulnerability April 2026.

No RRAS Vulnerabilities

RRAS has been a regular fixture in the monthly security updates, with several CVEs disclosed in most recent releases. September 2026 alone included eight RRAS CVEs, four of them rated Critical. It is refreshing to report that the November 2026 release includes no RRAS vulnerabilities at all.

Summary

This is a relatively light month for Always On VPN administrators. All three vulnerabilities are rated Important, and none are rated Critical. However, SSTP and IKE are both Internet-facing services in most Always On VPN deployments, so administrators should plan to deploy these updates during their next scheduled maintenance window and avoid unnecessary delays.

Additional Information

Always On VPN: Secure Remote Access for Windows

Microsoft November 2026 Security Updates

Always On VPN Security Updates September 2026

Leave a comment
by Richard M. Hicks on November 10, 2026  •  Permalink
Posted in Always On VPN, Security Updates, Windows Server
Tagged , , , , , , , , , ,

Posted by Richard M. Hicks on November 10, 2026

https://directaccess.richardhicks.com/2026/11/10/always-on-vpn-security-updates-november-2026/

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

1 Comment
by Richard M. Hicks on April 14, 2026  •  Permalink
Posted in Always On VPN, Security Updates, Windows Server
Tagged , , , , ,

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 Device Tunnel Fails to Connect Automatically

After the April 2024 Microsoft security updates were released, many Always On VPN administrators noticed that the device tunnel suddenly stopped connecting automatically for many, if not all, their endpoints.

Note: There were additional problems with the April 2024 security update that affected the Always On VPN device tunnel. Details here.

Troubleshooting

When this problem occurs, administrators can establish the device tunnel connection successfully if it is initiated manually. This indicates that there are no issues with the IKEv2 VPN connection or security configuration.

Subscription Activation

The root cause of this issue is related to a subscription activation issue broken in the April 2024 security updates. In this case, Windows 10/11 Enterprise Edition devices that were initially provisioned using Professional Edition and used a step-up upgrade (subscription activation) to Enterprise Edition are reverting to Professional Edition. The Always On VPN device tunnel requires Enterprise Edition to work correctly. Although you can deploy a device tunnel to Windows Professional, it will not connect automatically. It will, however, connect manually.

KB5040527

On July 25, 2024, Microsoft released a preview of updates (KB5040527), including a fix for this subscription activation issue. Administrators experiencing problems with Always On VPN device tunnels where their devices revert to Professional Edition can install this update to resolve this issue.

Additional Information

Always On VPN Device Tunnel Issue with the Microsoft April 2024 Security Update

Always On VPN Device Tunnel Status Indicator

Always On VPN Devcie Tunnel Only Deployment Considerations

4 Comments
by Richard M. Hicks on August 5, 2024  •  Permalink
Posted in Always On VPN, Security Updates
Tagged , , ,

Posted by Richard M. Hicks on August 5, 2024

https://directaccess.richardhicks.com/2024/08/05/always-on-vpn-device-tunnel-fails-to-connect-automatically/

What’s New in Always On VPN DPC 4.3.1

The latest release of PowerON Platforms’ Always On VPN Dynamic Profile Configurator (DPC), version 4.3.1, is now available for download. This recent update includes fixes for previously known issues. In addition, it contains some critical new features administrators will find helpful in addressing the challenges they face with Always On VPN client configuration.

What Is DPC?

Always On VPN DPC is a solution to manage Always On VPN client configuration settings. It was originally designed to be used with on-premises Active Directory but can also be deployed with Microsoft Intune. DPC streamlines the configuration and management of client settings and includes many advanced features to fine-tune and optimize Always On VPN.

What’s New in 4.3.1

The following essential features are new in the 4.3.1 release of DPC.

Add Device Tunnel Routes to User Tunnel

Always On VPN administrators can now configure DPC to add device tunnel routes to the user tunnel automatically. This configuration option ensures that all traffic flows of the user tunnel when both user and device tunnels are established.

Note: This feature also requires administrators to define route metric options in DPC. Ensure the user tunnel route metrics are set to a lower value than the device tunnel metrics for proper operation.

Restart RasMan

Always On VPN connections occasionally fail with error 602 (ERROR_PORT_ALREADY_OPEN). The workaround for this is to restart the RasMan service on the endpoint. DPC now supports automatically restarting the RasMan service when this error occurs, ensuring reliable operation for Always On VPN connections.

Machine Certificate Filtering

DPC 4.3.1 now includes a feature to allow administrators to enable machine certificate filtering for Always On VPN device tunnels. This addresses a challenge when the endpoint has multiple machine certificates in its local computer certificate store when the VPN server is configured to accept a certificate with a specific custom application policy (EKU).

Additional Features

In addition, the updated DPC agent core service now run as x64 processes. Also, DPC now supports VPN server FQDNs longer than 63 characters (good news for those using DPC with Azure VPN gateway!).

Download DPC

For those customers currently licensed for Always On VPN DPC you can download the latest release here.

https://support.poweronplatforms.com/support/solutions/articles/8000066807

Not using DPC?

If you’re not using DPC, you are missing out! You can learn more about DPC and register for a free evaluation by visiting the link below.

https://aovpndpc.com

Optionally, you can fill out the form below and I’ll provide you with more information.

Additional Information

PowerON Platforms’ Always On VPN Dynamic Profile Configurator (DPC)

Always On VPN DPC Advanced Features

Always On VPN DPC with Microsoft Intune

Leave a comment
by Richard M. Hicks on June 3, 2024  •  Permalink
Posted in Always On VPN, Always On VPN DPC, Certificate-Based Authentication, Microsoft Intune, PKI, Windows Server
Tagged , , , , , , , , , ,

Posted by Richard M. Hicks on June 3, 2024

https://directaccess.richardhicks.com/2024/06/03/whats-new-in-always-on-vpn-dpc-4-3-1/

Always On VPN Device Tunnel Issues with April 2024 Security Update

Always On VPN administrators may find that their device tunnel connections no longer connect automatically after applying the April 2024 security updates. The device tunnel connection is optional and only required under specific conditions, so end users may not be immediately impacted. However, administrators should be aware of this issue.

Note: The issues outlined in this post have been resolved with the May 14, 2024, security updates.

Error Messages

When manually establishing an Always On VPN device tunnel connection using rapshone.exe or rasdial.exe, you may receive one of the following error messages.

Rasphone.exe

Error 0x80070057: The parameter is incorrect.

Rasdial.exe

Connecting to <Name of Device Tunnel>…The parameter is incorrect.

Affected Devices

The issue affects all supported versions of Windows with an Always On VPN device tunnel connection configured to require a specific Enhanced Key Usage (EKU) OID. Administrators can run the following PowerShell command to identify this configuration.

Get-VpnConnection -AllUserConnection -Name <Name of Device Tunnel> | Select-Object MachineCertificateEkuFilter

If the output of this PowerShell command returns data, it is affected by this issue.

Workaround

To restore Always On VPN device tunnel functionality on devices with the April 2024 security updates installed, open an elevated PowerShell command window and run the following command.

Set-VpnConnection -AllUserConnection -Name ‘Always On VPN Device Tunnel’ -MachineCertificateEKUFilter $Null

After running this command, the output should now be blank.

Caveat

The problem with implementing the workaround described here is that you likely enabled this configuration to address an issue where the wrong certificate was selected for use with the device tunnel. In this case, the workaround may result in unexpected behavior and may not restore full functionality.

Known Issue Rollback

Currently, Microsoft is aware of the issue and is actively working to resolve it. If you are experiencing this issue, open a support case with Microsoft, and they will provide you with more information and possibly a private Known Issue Rollback (KIR). I will update this post as soon as Microsoft publishes a permanent fix.

Additional Information

Always On VPN Device Tunnel Operation and Best Practices

Always On VPN Device Tunnel Only Deployment Considerations

Considerations for Always On VPN with Azure VPN Gateway and Virtual WAN

2 Comments
by Richard M. Hicks on April 23, 2024  •  Permalink
Posted in Always On VPN, Certificate-Based Authentication, PKI, PowerShell, Security Updates
Tagged , , , , ,

Posted by Richard M. Hicks on April 23, 2024

https://directaccess.richardhicks.com/2024/04/23/always-on-vpn-device-tunnel-issues-with-april-2024-security-update/

Considerations for Always On VPN with Azure VPN Gateway and Virtual WAN

Always On VPN Device Tunnel and Custom Cryptography Native Support Now in Intune

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.

In addition, Azure does not support routing traffic to on-premises RADIUS servers over ExpressRoute connections. In this scenario, administrators must route RADIUS traffic to on-premises servers over a site-to-site connection.

Geographic Redundancy

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.

Additional Information

Always On VPN Options for Azure Deployments

Always On VPN with Azure Gateway

Always On VPN Device Tunnel with Azure VPN Gateway

Always On VPN and RRAS in Azure

What is Azure VPN Gateway?

What is Azure Virtual WAN?

3 Comments
by Richard M. Hicks on January 31, 2024  •  Permalink
Posted in Always On VPN, Authentication and MFA, Azure and AWS, Conditional Access, Entra ID, IPv6, Load Balancing, NPS and EAP, PKI, Windows Server
Tagged , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on January 31, 2024

https://directaccess.richardhicks.com/2024/01/31/considerations-for-always-on-vpn-with-azure-vpn-gateway-and-virtual-wan/

Always On VPN RRAS and Stale Connections

Always On VPN Updates for RRAS and IKEv2

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.

Additional Information

Always On VPN Updates for RRAS and IKEv2

Always On VPN IKEv2 Load Balancing and NAT

Always On VPN and IKEv2 Fragmentation

Leave a comment
by Richard M. Hicks on March 14, 2023  •  Permalink
Posted in Always On VPN, PowerShell, Security Updates, Windows Server
Tagged , , , , , , , , , , , ,

Posted by Richard M. Hicks on March 14, 2023

https://directaccess.richardhicks.com/2023/03/14/always-on-vpn-rras-and-stale-connections/

Always On VPN Error 13806

Troubleshooting Always On VPN Error 691 and 812 – Part 2

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.

Additional Information

Microsoft Windows Always On VPN Error 13801

Microsoft Windows Always On VPN Certificate Requirements for IKEv2

Microsoft Windows Always On VPN IPsec Root Certificate Configuration Issue

Microsoft Windows Always On VPN IKEv2 Policy Mismatch Error

Microsoft Windows Always On VPN IKEv2 Security Configuration

Microsoft Windows Always On VPN IKEv2 Fragmentation

Microsoft Windows Always On VPN IKEv2 Load Balancing and NAT

Microsoft Windows Always On VPN IKEv2 Features and Limitations

16 Comments
by Richard M. Hicks on December 20, 2021  •  Permalink
Posted in Always On VPN, PKI, PowerShell, Windows Server
Tagged , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on December 20, 2021

https://directaccess.richardhicks.com/2021/12/20/always-on-vpn-error-13806/

Always On VPN Error 13801

Troubleshooting Always On VPN Error 691 and 812 – Part 2

Certificate configuration is crucial for Always On VPN deployments. I described some specific certificates requirements for IKEv2 in this previous 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 13801

One of the most common errors related to IKEv2 and certificates is 13801. 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 13801”.

IKE Authentication Credentials are Unacceptable

Error 13801 translates to ERROR_IPSEC_IKE_AUTH_FAIL, indicating an authentication failure related to IPsec. The problem can be on the device, the VPN server, or an issue with the VPN server configuration.

Authentication Methods

To begin, ensure that the appropriate authentication method is enabled on the Routing and Remote Access (RRAS) server. Right-click the VPN server in the RRAS management console (rrasmgmt.msc) and choose Properties. Next, click on the Security tab and then click on the Authentication Methods button.

Select the ‘Extensible authentication protocol (EAP)’ to support IKEv2 user tunnel connections. In addition, select ‘Allow machine certificate authentication for IKEv2’ to support Always On VPN device tunnel connections.

Certificate Chain

A 13801 error will occur 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 13801 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 13801 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 13801 error for the device tunnel is a misconfigured Routing and Remote Access Service (RRAS) VPN server. An error 13801 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.

Additional Information

Microsoft Windows Always On VPN Error 13806

Microsoft Windows Always On VPN Certificate Requirements for IKEv2

Microsoft Windows Always On VPN IPsec Root Certificate Configuration Issue

Microsoft Windows Always On VPN IKEv2 Policy Mismatch Error

Microsoft Windows Always On VPN IKEv2 Security Configuration

Microsoft Windows Always On VPN IKEv2 Fragmentation

Microsoft Windows Always On VPN IKEv2 Load Balancing and NAT

Microsoft Windows Always On VPN IKEv2 Features and Limitations

23 Comments
by Richard M. Hicks on December 13, 2021  •  Permalink
Posted in Always On VPN, Authentication and MFA, PKI, PowerShell, Windows Server
Tagged , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on December 13, 2021

https://directaccess.richardhicks.com/2021/12/13/always-on-vpn-error-13801/

Always On VPN Class-Based Default Route and Intune

`Always On VPN Class-Based Default Route and IntuneIn a recent post, I described how to configure routing for Windows 10 Always On VPN clients. In that article, I shared guidance for disabling the class-based default route in favor of defining specific routes for the VPN client. While this is easy enough to do when you use custom XML (deployed via PowerShell, SCCM, or Intune), there is a known limitation when using the native Intune UI that could present some challenges.

Updated 11/9/2024 to include update information for a workaround using Intune Remediation.

Intune VPN Profile Configuration

Defining specific routes is easy to do in Intune using the native VPN configuration profile. In the Configuration settings expand Split Tunneling and click Enable. The administrator can then add routes by entering their Destination prefix and Prefix size, as shown here.

Always On VPN Class-Based Default Route and Intune

Class-Based Default Route

The limitation with using Intune to configure routes is that there is currently no option to disable the class-based default route as there is with custom XML. This means the routes shown in the example above will be added to the client, but the class-based route will also be added automatically, as shown here (class-based default route highlighted with the arrow).

Always On VPN Class-Based Default Route and Intune

Considerations

In most cases, the inclusion of the class-based default route along with the administrator-defined routes will not be a problem. However, in some scenarios, it could yield unexpected results. Specifically, Always On VPN clients may have unintended access to some networks over the VPN tunnel. This is most significant for the Always On VPN device tunnel, where it is common to limit access to only specific resources using individual host routes.

Workaround

As a workaround, administrators can use Intune Remediations to disable the class-based default route post-deployment. Sample detection and remediation scripts for the user and device tunnel can be found here.

https://github.com/richardhicks/endpointmanager/blob/main/Detect-DeviceDisableClassBasedDefaultRoute.ps1

https://github.com/richardhicks/endpointmanager/blob/main/Remediate-DeviceDisableClassBasedDefaultRoute.ps1

https://github.com/richardhicks/endpointmanager/blob/main/Detect-UserDisableClassBasedDefaultRoute.ps1

https://github.com/richardhicks/endpointmanager/blob/main/Remediate-UserDisableClassBasedDefaultRoute.ps1

Additional Information

Deploying Windows 10 Always On VPN with Intune and Custom XML

Deploying Windows 10 Always On VPN Device Tunnel with Intune and Custom XML

Windows 10 Always On VPN Routing Configuration

Windows 10 Always On VPN Device Tunnel Operation and Best Practices

5 Comments
by Richard M. Hicks on March 4, 2021  •  Permalink
Posted in Always On VPN, Microsoft Intune, PowerShell
Tagged , , , , , , , , , , ,

Posted by Richard M. Hicks on March 4, 2021

https://directaccess.richardhicks.com/2021/03/04/always-on-vpn-class-based-default-route-and-intune/

« Older Posts