Always On VPN PowerShell Script Issues in Windows 11

Many administrators are now beginning to test Always On VPN functionality on the latest Microsoft Windows client operating system, Windows 11. Initially, Microsoft had some issues with provisioning and managing Always On VPN profiles on Windows 11 using Microsoft Endpoint Manager/Intune, but those have been resolved. However, some lingering problems may delay enterprise deployments of Always On VPN on Windows 11 for some organizations, specifically those using PowerShell with Active Directory group policy startup scripts or System Center Configuration Manager (SCCM).

MakeProfile.ps1

Microsoft has published guidance for deploying Always On VPN profiles using PowerShell with their MakeProfile.ps1 script. This script extracts configuration details from a template VPN profile to create another PowerShell script called VPN_Profile.ps1, which is used to create the Always On VPN profile. SCCM administrators commonly use VPN_Proifle.ps1 to deploy Always On VPN profiles. However, running this script on Windows 11 fails and returns the following error message.

“Unable to create [VPN profile name] profile: A general error occurred that is not covered by a more specific code.”

This issue appears to be related to a problem with the WMI-to-CSP bridge, specifically enumerating the MDM_VPNv2_01 class in the root\cimv2\mdm\dmmap namespace. Here you can see the template VPN profile with PowerShell and Get-VpnConnection.

However, attempts to view the MDM_VPNv2_01 class of this VPN profile using PowerShell and Get-CimInstance fail.

New-AovpnConnection.ps1

Interestingly, administrators may find that my Always On VPN PowerShell deployment script works more reliably on Windows 11, although not always. In my experience, I’ve found that it sometimes fails once (profile is loaded, but the configuration is incomplete), then works after deleting the profile and creating it again. If the Microsoft-provided script isn’t working, give mine a try and see if it works better for you.

Note: When deploying Always On VPN profiles using my PowerShell deployment script via Active Directory startup scripts, it seems to fail consistently for some reason. Go figure. 😉

Remove-AovpnConnection.ps1

The issues described previously with Windows 11 are also negatively affecting some of my other PowerShell scripts. For example, running Remove-Aovpnconnection.ps1 on Windows 11 fails and returns the following error message.

“A general error occurred that is not covered by a more specific error code.”

Current Status

Microsoft is currently aware of this issue. However, I am aware of no timeframe for resolution at the time of this writing. Hopefully, Microsoft addresses this soon so organizations can move forward with their Windows 11 migration projects.

Additional Information

Microsoft Windows Always On VPN Windows 11 Issues with Microsoft Endpoint Manager/Intune

Microsoft Windows Always On VPN Profile Deployment Script

Microsoft Windows Always On VPN Remove Always On VPN Profile Script

Always On VPN PowerShell Script Repository on GitHub

Always On VPN and Zero Trust Network Access (ZTNA)

Always On VPN and Zero Trust Network Access (ZTNA)

Zero Trust Network Access (ZTNA) is a term that administrators are likely familiar with, as it is one of the hottest marketing buzzwords in circulation today. ZTNA can mean different things depending on the deployment scenario. ZTNA is fundamentally about enforcing the principle of least privilege for endpoints connecting remotely to the corporate network when it comes to enterprise mobility and remote access.

Trusted Access

Historically, VPNs and even DirectAccess granted full, unrestricted network access to authenticated devices and users. Once the endpoint has an IP address, and in the absence of other controls (routing limitations, firewall access controls, etc.), the user could access any resource on the internal network. The rationale was that authenticated devices and users should be considered “trusted”.

Limitations

The Trusted Access model has some significant limitations. It assumes that all traffic from authorized users and devices is legitimate. However, if an endpoint is compromised, an attacker has broad access to the internal network, which is not ideal from a security perspective.

Zero Trust

Zero Trust Network Access is a concept where administrators define explicitly the minimum level of access required to support remote workers. Instead of granting full network access to the endpoint, controlling access using fine-grained policies is enforced on the VPN connection. Configuring limited network access for Always On VPN clients dramatically reduces exposure of the internal network to compromised endpoints.

ZTNA Management

There is a significant management burden associated with this approach, however. Administrators must identify each application requiring VPN access and determine all associated protocols and ports to be allowed, and internal resources to which they will communicate. Although this task isn’t difficult if clients require access to a small subset of internal resources, it can be a substantial undertaking if clients require access to many internal resources from numerous client applications.

Moving Targets

Making things more challenging is that application and network infrastructure often change constantly, requiring administrators to manage network access continually to ensure application availability. When adding new applications or changing the internal infrastructure, updating the configuration on all remote endpoints will be required.

Updating Always On VPN configuration for devices managed with Microsoft Endpoint Manager (formerly Intune) isn’t difficult. However, it can be more challenging when using PowerShell with System Center Configuration Manager (SCCM) or another endpoint management platform.

Traffic Filters

ZTNA can be configured with Always On VPN using Traffic Filters. With Traffic Filters, administrators can apply fine-grained access control for VPN traffic based on a combination of the following.

  • Source IP address (IP address, address range, or subnet)
  • Destination IP address (IP address, address range, or subnet)
  • Protocol (TCP, UDP, IP, etc.)
  • Source Port
  • Destination Port

Endpoint Manager Configuration

Configuring Traffic Filters for Always On VPN connections can be performed using Microsoft Endpoint Manager. Open the Endpoint Manager management console (https://endpoint.microsoft.com), navigate to the Always On VPN device configuration profile, then perform the following steps.

  1. Expand App and Traffic Rules.
  2. Click Add next to Network traffic rules for this VPN connection.
  1. Enter a descriptive name in the Name field.
  2. Select Split tunnel from the Rule type drop-down list.
  3. Enter “6” in the Protocol field.
  4. Enter “3389” in the Lower port and Upper port fields in the Remote port ranges section.
  5. Enter an IPv4 address in the Lower IPv4 address field.
  6. Enter an IPv4 address in the Upper IPv4 address field. Enter the same IPv4 address as the lower address to specify a single host.
  7. Click Save.

The example above shows a traffic filter restricting access to TCP port 3389 (Remote Desktop Protocol) from all VPN clients to the 172.16.0.0/24 network.

Note: Repeat these steps to create as many traffic filters as required for any processes or applications that must communicate over the Always On VPN connection.

XML Configuration

Traffic Filters can also be configured using custom XML. To implement the same Traffic Filter described previously, add the following code between the <VPNProfile> and </VPNProfile> tags in your XML configuration file.

<TrafficFilter>
   <Protocol>6</Protocol>
   <RemotePortRanges>3389</LocalPortRanges>
   <RemoteAddressRanges>172.16.0.0/24</RemoteAddressRanges>
</TrafficFilter>

Note: Address ranges used in Traffic Filters can be defined using CIDR notation in XML, but they are not supported using Microsoft Endpoint Manager today.

Default Deny

When configuring a Traffic Filter for an Always On VPN profile, an implicit “deny all” rule is automatically enabled. Any traffic not explicitly defined in a Traffic Filter will be denied, including unsolicited inbound traffic, which has crucial implications for the device tunnel because it is used commonly for system management of remote devices.

Direction

Traffic Filters are enabled for the Outbound direction only, by default. Beginning with Windows 10 2004, Microsoft introduced support for Inbound traffic filters. Before Windows 10 2004, configuring a Traffic Filter on the device tunnel would break manage-out scenarios by denying all unsolicited inbound network access.

As of this writing, configuring inbound Traffic Filters using Microsoft Endpoint Manager is not supported. They are only configurable using custom XML.

To implement a Traffic Filter to allow inbound RDP access from the internal network over the device tunnel, add the following code between the <VPNProfile> and </VPNProfile> tags in your XML configuration file.

<TrafficFilter>
   <Protocol>6</Protocol>
   <LocalPortRanges>3389</LocalPortRanges>
   <RemoteAddressRanges>172.16.0.0/16</RemoteAddressRanges>
   <Direction>Inbound</Direction>
</TrafficFilter>

Note: When configuring inbound Traffic Filters, specify the port of the listening process or application using the LocalPortRanges field.

Application Filters

Administrators can combine Application Filters with Traffic Filters to control network access over the Always On VPN connection even more granularly. Applications can be defined by the following.

  • Package Family Name (PFN) – This is the unique name of a Microsoft Store application. Use the Get-AppxPackage PowerShell command to find the PFN for an application.
  • File Path – This is the full path to any executable on the file system. For example, c:\Windows\System32\mstsc.exe.
  • SYSTEM – This allows Windows kernel-mode drivers (such as ping.exe and net.exe) to send traffic over the Always On VPN connection.

As of this writing, configuring Application Filters using Microsoft Endpoint Manager is not supported. They are only configurable using custom XML.

Application Filter Examples

Below are three examples showing different Application Filters based on file path, Package Family Name, and SYSTEM.

File Path

This example shows a Traffic Filter configured to allow RDP access to an internal subnet using the native Windows Remote Desktop client (mstsc.exe).

<TrafficFilter>
   <App>
      <Id>C:\Windows\System32\mstsc.exe</Id>
   </App>
   <Protocol>6</Protocol>
   <RemotePortRanges>3389</RemotePortRanges>
   <RemoteAddressRanges>172.16.0.0/24</RemoteAddressRanges>
</TrafficFilter>

Package Family Name

This example shows a Traffic Filter configured to allow RDP access to an internal subnet using the Microsoft Windows Store Remote Desktop client.

<TrafficFilter>
   <App>
      <Id>Microsoft.RemoteDesktop_8wekyb3d8bbwe</Id>
   </App>
   <Protocol>6</Protocol>
   <RemotePortRanges>3389</RemotePortRanges>
   <RemoteAddressRanges>172.16.0.0/24</RemoteAddressRanges>
</TrafficFilter>

SYSTEM

This example shows a Traffic Filter configured to allow the netsh.exe process access to an internal subnet.

<TrafficFilter>
   <App>
      <Id>SYSTEM</Id>
   </App>
   <Protocol>6</Protocol>
   <RemotePortRanges>445</RemotePortRanges>
   <RemoteAddressRanges>172.16.0.0/24</RemoteAddressRanges>
</TrafficFilter>

This example shows a Traffic Filter configured to allow the ping.exe process access to an internal subnet.

<TrafficFilter>
   <App>
      <Id>SYSTEM</Id>
   </App>
   <Protocol>1</Protocol>
   <RemoteAddressRanges>172.16.0.0/24</RemoteAddressRanges>
</TrafficFilter>

Note: Ping uses ICMP (IP protocol 1), which is a network layer protocol. As such, defining ports for the filter is not required.

IPv6 Compatibility

Sadly, the filtering techniques described in this article do not work when also configuring IPv6 on the Always On VPN connection. As of this writing, enabling Traffic Filters when an IPv6 address is assigned to the VPN interface is not supported. More details can be found here.

Always On VPN Traffic Filters and IPv6

Summary

Configuring Zero Trust Network Access (ZTNA) with Windows 10 Always On VPN is not trivial. Still, with attention to detail, it can be a highly effective tool to enforce fine-grained network access policies and reduce exposure of the internal network to compromised endpoints. Combining Traffic Filters with Application Filters allows administrators to tightly control Always On VPN access and ensure the principle of least privilege is applied.

Additional Information

Windows 10 Always On VPN Traffic Filters and IPv6

Windows 10 Always On VPN User Tunnel XML Configuration Reference File

Windows 10 Always On VPN Device Tunnel XML Configuration Reference File

Windows 10 Always On VPN VPNv2 CSP Reference

IP Protocol Numbers

Always On VPN Traffic Filters and IPv6

Always On VPN Windows Server RRAS Service Does Not Start

Using Traffic Filters with Always On VPN provides administrators the option to configure a true Zero Trust Network Access (ZTNA) solution for their field-based users and devices. By enabling traffic filtering, network access over the Always On VPN connection can be controlled using fine-grained policies. Traffic Filter rules can be configured to restrict access based source and destination IP addresses, protocols, and source and destination ports. Administrators can further restrict access based on the application generating the traffic.

IPv6

While testing these features recently, I learned that the Microsoft Endpoint Manager (formerly Intune) user interface does not appear to support IPv6 when configuring traffic filter rules. As you can see here, the UI explicitly asks for an IPv4 address and complains when entering an IPv6 address in the address field, as shown here.

Interestingly, it is possible to add IPv6 addresses in XML, as follows.

<TrafficFilter>
   <App>
      <Id>Microsoft.RemoteDesktop_8wekyb3d8bbwe</Id>
   </App>
   <Protocol>6</Protocol>
   <RemotePortRanges>3389</RemotePortRanges>
   <RemoteAddressRanges>2001:470:f109::/48</RemoteAddressRanges>
</TrafficFilter>

Connection Failure

Unfortunately, after loading the XML on a test client, the Always On VPN connection fails with the following error message.

“Can’t connect to <ConnectionName>. Catastrophic failure.”

In addition, the Application event log records an event ID 20227 from the RasClient source with the following error.

“The user <UserName> dialed a connection name <ConnectionName> which has failed. The error code returned on failure is -2147418113.”

Workaround

At this time, the only known workaround is to update the configuration on the RRAS server to use IPv4 addressing for VPN clients.

Summary

Unfortunately, IPv6 is still a second-class citizen when it comes to Always On VPN. Although enabling IPv6 works well in most common deployment scenarios, the Microsoft Endpoint Manager management console often fails to accept IPv6 entries in IP address fields. In addition, some advanced features such as traffic filtering are incompatible with IPv6.

Additional Information

Windows 10 Always On VPN and Zero Trust Network Access (ZTNA)

Windows 10 Always On VPN Windows Server RRAS Service Does Not Start

%d bloggers like this: