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

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.

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

Today there is no option to disable the class-based default route using the native Intune UI. Your only option is to deploy the Always On VPN profile using custom XML, as described here.

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

Removing Always On VPN Connections

Removing Always On VPN ConnectionsMuch has been written about provisioning Windows 10 Always On VPN client connections over the past few years. While the preferred method for deploying Always On VPN is Microsoft Intune, using PowerShell is often helpful for initial testing, and required for production deployment with System Center Configuration Manager (SCCM) or Microsoft Endpoint Manager (MEM). That said, there will invariably come a time when an administrator has to remove an Always On VPN connection. It is not as simple as you might think.

PowerShell

There are a variety of ways to remove an existing Always On VPN connection, with the quickest and simplest being PowerShell and the Remove-VpnConnection cmdlet.

Get-VpnConnection -Name ‘Always On VPN’ | Remove-VpnConnection -Force

There are several limitations to this method, however.

Active Connections

Administrators will quickly realize that PowerShell fails to remove a VPN connection that is currently connected. As shown here, attempting to remove an active VPN connection will return the following error message.

“The VPN connection [connection name] cannot be removed from the local user connections. Cannot delete a connection while it is connected.”

Removing Always On VPN Connections

Registry Artifacts

Removing Always On VPN connections using PowerShell commonly leaves behind registry artifacts that can potentially cause problems. For example, there are several Always On VPN-related registry entries in several locations including the HKLM\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked hive that may not be deleted when removing an Always On VPN connection. When provisioning a new Always On VPN connection after deleting one with the same name previously, the administrator may encounter the following error message.

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

Removing Always On VPN Connections

Note: This error can also be caused by improperly formatted XML configuration files. More details here.

Remove-AovpnConnection Script

Veteran Always On VPN administrators are likely familiar with PowerShell scripts I’ve created called New-AovpnConneciton.ps1 and New-AovpnDeviceConnection.ps1, which are hosted on my GitHub. These scripts are adapted from code samples published by Microsoft to which I have included additional functionality. To address the limitations highlighted in this article I have published a new PowerShell script called Remove-AovpnConnection.ps1. It will remove any Always On VPN connection, even those that are currently active. It also includes logic to remove known registry artifacts common to Always On VPN. Download the script from GitHub and use the following syntax to remove an Always On VPN connection, established or not.

.\Remove-AovpnConnection.ps1 -ProfileName [connection name]

Running this PowerShell command will forcibly remove an Always On VPN connection. Use the -DeviceTunnel switch when removing a device tunnel connection (requires running in the system context). I have also included a -CleanUpOnly switch to remove registry artifacts when the VPN connection was previously removed using another method.

Updated Installation Scripts

I have also updated New-AovpnConnection.ps1 to include these registry clean up steps. This will prevent future errors when provisioning an Always On VPN client where a connection of the same name was removed previously.

Note: New-AovpnConnection.ps1 has also been updated to support device tunnel deployments. As such, I have deprecated New-AovpnDeviceConnection.ps1. Simply use New-AovpnConnection.ps1 with the -DeviceTunnel switch to deploy an Always On VPN device tunnel.

Additional Information

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Troubleshooting Always On VPN Unable to Create Profile General Error

 

Always On VPN with Azure Gateway

Always On VPN with Azure GatewayRecently I wrote about VPN server deployment options for Windows 10 Always On VPN in Azure. In that post I indicated the native Azure VPN gateway could be used to support Always On VPN connections using Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP). In this post I’ll outline the requirements and configuration steps for implementing this solution.

Requirements

To support Always On VPN, point-to-site VPN connections must be enabled on the Azure VPN gateway. Not all Azure VPN gateways are alike, and point-to-site connections are not supported in all scenarios. For Always On VPN, the Azure VPN gateway must meet the following requirements.

VPN SKU

The Azure VPN gateway SKU must be VpnGw1, VpnGw2, VpnGw3, VpnGw1AZ, VpnGw2AZ, or VpnGw3AZ. The Basic SKU is not supported.

VPN Type

The VPN type must be route-based. Policy-based VPN gateways are not supported for point-to-site VPN connections.

Limitations

Using the Azure VPN gateway for Always On VPN may not be ideal in all scenarios. The following limitations should be considered thoroughly before choosing the Azure VPN gateway for Always On VPN.

Device Tunnel

RADIUS/EAP authentication for user tunnel connections is not supported if the Azure VPN gateway is configured to support device tunnel with machine certificate authentication.

Maximum Connections

A maximum of 250, 500, and 1000 concurrent IKEv2 connections are supported when using the VpnGw1/AZ, VpnGw2/AZ, and VpnGw3/AZ SKUs, respectively (x2 for active/active gateway deployments). In addition, a maximum of 128 concurrent SSTP connections are supported for all VPN gateway SKUs (x2 for active/active gateway deployments).

Always On VPN with Azure Gateway

Reference: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpngateways#gwsku

RADIUS Requirements

To support Always On VPN connections, the Azure VPN gateway must be configured to authenticate to a RADIUS server. The RADIUS server must be reachable from the VPN gateway subnet. The RADIUS server can be hosted in Azure or on-premises. Before proceeding, ensure that any network routes, firewall rules, and site-to-site VPN tunnel configuration is in place to allow this communication.

RADIUS Configuration

Guidance for configuring Windows Server NPS for Always On VPN can be found here. The only difference when configuring NPS for use with Azure VPN gateway is the RADIUS client configuration.

Open the NPS management console (nps.msc) and follow the steps below to configure Windows Server NPS to support Always On VPN client connections from the Azure VPN gateway.

1. Expand RADIUS Clients and Servers.
2. Right-click RADIUS Clients and choose New.
3. Enter a descriptive name in the Friendly name field.
4. Enter the Azure VPN gateway subnet using CIDR notation in the Address (IP or DNS) field. The gateway subnet can be found by viewing the properties of the Azure VPN gateway in the Azure portal.
5. Enter the shared secret to be used for RADIUS communication in the Shared secret field.

Always On VPN with Azure Gateway

Azure VPN Gateway Configuration

To begin, provision a Virtual Network Gateway in Azure that meets the requirements outlined above. Guidance for implementing an Azure VPN gateway can be found here. Once complete, follow the steps below to enable support for Always On VPN client connections.

Enable Point-to-Site

Perform the following steps to enable point-to-site VPN connectivity.

1. In the navigation pane of the Azure VPN gateway settings click Point-to-site configuration.
2. Click Configure Now and specify an IPv4 address pool to be assigned to VPN clients. This IP address pool must be unique in the organization and must not overlap with any IP address ranges defined in the Azure virtual network.
3. From the Tunnel type drop-down list select IKEv2 and SSTP (SSL).
4. In the RADIUS authentication field enter the IPv4 address of the RADIUS server. At the time of this writing only a single IPv4 address is supported. If RADIUS redundancy is required, consider creating a load balanced NPS cluster.
5. In the Server secret field enter the RADIUS shared secret.
6. Click Save to save the configuration.

Always On VPN with Azure Gateway

VPN Client Configuration

Perform the following steps to configure a Windows 10 VPN client to connect to the Azure VPN gateway.

Download VPN Configuration

1. Click Point-to-site configuration.
2. Click Download VPN client.
3. Select EAPMSCHAv2 (yes, that’s correct even if EAP-TLS will be used!)
4. Click Download.
5. Open the downloaded zip file and extract the VpnSettings.XML file from the Generic folder.
6. Copy the FQDN in the VpnServer element in VpnSettings.XML. This is the FQDN that will be used in the template VPN connection and later in ProfileXML.

Always On VPN with Azure Gateway

Create a Test VPN Connection

On a Windows 10 device create a test VPN profile using the VPN server address copied previously. Configure EAP settings to match those configured on the NPS server and test connectivity.

Create an Always On VPN Connection

Once the VPN has been validated using the test profile created previously, the VPN server and EAP configuration from the test profile can be used to create the Always On VPN profile for publishing using Intune, SCCM, or PowerShell.

IKEv2 Security Configuration

The default IKEv2 security parameters used by the Azure VPN gateway are better than Windows Server, but the administrator will notice that a weak DH key (1024 bit) is used in phase 1 negotiation.

Always On VPN with Azure Gateway

Use the following PowerShell commands to update the default IKEv2 security parameters to recommended baseline defaults, including 2048-bit keys (DH group 14) and AES-128 for improved performance.

Connect-AzAccount
Select-AzSubscription -SubscriptionName [Azure Subscription Name]

$Gateway = [Gateway Name]
$ResourceGroup = [Resource Group Name]

$IPsecPolicy = New-AzVpnClientIpsecParameter -IpsecEncryption AES128 -IpsecIntegrity SHA256 -SALifeTime 28800 -SADataSize 102400000 -IkeEncryption AES128 -IkeIntegrity SHA256 -DhGroup DHGroup14 -PfsGroup PFS14

Set-AzVpnClientIpsecParameter -VirtualNetworkGatewayName $Gateway -ResourceGroupName $ResourceGroup -VpnClientIPsecParameter $IPsecPolicy

Note: Be sure to update the cryptography settings on the test VPN connection and in ProfileXML for Always On VPN connections to match the new VPN gateway settings. Failing to do so will result in an IPsec policy mismatch error.

Additional Information

Microsoft Azure VPN Gateway Overview

About Microsoft Azure Point-to-Site VPN

Windows 10 Always On VPN IKEv2 Security Configuration

 

 

 

Always On VPN Device Tunnel Configuration using Intune

Always On VPN Device Tunnel Configuration using IntuneA while back I described in detail how to configure a Windows 10 Always On VPN device tunnel connection using PowerShell. While using PowerShell is fine for local testing, it obviously doesn’t scale well. In theory you could deploy the PowerShell script and XML file using System Center Configuration Manager (SCCM), but using Microsoft Intune is the recommended and preferred deployment method. However, as of this writing Intune does not support device tunnel configuration natively. The administrator must create a ProfileXML manually and use Intune to deploy it.

Device Tunnel Prerequisites

I outlined the Always On VPN device tunnel prerequisites in my previous post here. To summarize, the client must be running Windows 10 Enterprise edition and be domain-joined. It must also have a certificate issued by the internal PKI with the Client Authentication EKU in the local computer certificate store.

ProfileXML

To begin, create a ProfileXML for the device tunnel that includes the required configuration settings and parameters for your deployment. You can find a sample Windows 10 Always On VPN device tunnel ProfileXML here.

Note: Be sure to define a custom IPsec policy in ProfileXML for the device tunnel. The default security settings for the IKEv2 protocol (required for the device tunnel) are quite poor. Details here.

Intune Deployment

Open the Intune management console and follow the steps below to deploy an Always On VPN device tunnel using Microsoft Intune.

Create Profile

1. Navigate to the Intune portal.
2. Click Device configuration.
3. Click Profiles.
4. Click Create profile.

Define Profile Settings

1. Enter a name for the VPN connection in the Name field.
2. Enter a description for the VPN connection in the Description field (optional).
3. Select Windows 10 and later from the Platform drop-down list.
4. Select Custom from the Profile type drop-down list.

Always On VPN Device Tunnel Configuration using Intune

Define Custom OMA-URI Settings

1. On the Custom OMA-URI Settings blade click Add.
2. Enter a name for the device tunnel in the Name field.
3. Enter a description for the VPN connection in the Description field (optional).
4. Enter the URI for the device tunnel in the OMA-URI field using the following syntax. If the profile name includes spaces they must be escaped, as shown here.

./Device/Vendor/MSFT/VPNv2/Example%20Profile%Name/ProfileXML

5. Select String (XML file) from the Data Type drop-down list.
6. Click the folder next to the Select a file field and chose the ProfileXML file created previously.
7. Click Ok twice and then click Create.

Always On VPN Device Tunnel Configuration using Intune

Assign Profile

Follow the steps below to assign the Always On VPN device tunnel profile to the appropriate device group.

1. Click Assignments.
2. Click Select groups to include.
3. Select the group that includes the Windows 10 client devices.
4. Click Select.
5. Click Save.

Always On VPN Device Tunnel Configuration using Intune

Demonstration Video

A video demonstration of the steps outlined above can be viewed here.

Additional Information

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN IKEv2 Security Configuration

Deleting a Windows 10 Always On VPN Device Tunnel

Windows 10 Always On VPN Device Tunnel Missing in the UI

Video: Deploying Windows 10 Always On VPN User Tunnel with Microsoft Intune

Always On VPN ProfileXML Editing and Formatting with Visual Studio Code

Always On VPN ProfileXML Editing and Formatting with Visual Studio CodeWindows 10 Always On VPN is designed to be implemented and managed using a Mobile Device Management (MDM) platform such as Microsoft Intune. With Intune specifically, there is an option to configure an Always On VPN profile in the UI. However, it provides only limited support and does not include all settings and options required for many deployments. Crucially, IKEv2 advanced security settings cannot be configured using the Intune portal. Also, there is currently no option for configuring a device tunnel with Intune. In these scenarios the administrator must manually create a ProfileXML file and provision it using Intune, System Center Configuration Manager (SCCM), or PowerShell.

ProfileXML

ProfileXML includes all settings that define the Always On VPN connection. The options and settings available are documented in the VPNv2 Configuration Service Provider (CSP) reference on Microsoft’s web site. ProfileXML is formatted using elements and settings within those elements. The formatting and syntax are critical to ensuring proper operation. Any error in syntax or formatting can result in an error, such as those described here.

XML Readability

Formatting is also important for readability, which is often helpful when reviewing configuration settings or troubleshooting syntax errors. For example, an element may be defined correctly but may be nested wrong. Often XML files are created with all text being left-justified, or with everything on a single line, making the content difficult to read. Using a file editor that recognizes XML files can be beneficial.

Visual Studio Code

To create, edit, and review ProfileXML it is recommended that a proper editing tool be used. I recommend using Microsoft’s Visual Studio Code. It is free, and it is especially helpful when editing XML files. Visual Studio Code can be downloaded here.

XML Tools VS Code Plug-In

To further enhance Visual Studio Code’s XML editing and formatting capabilities I recommend installing the XML Tools plug-in. This tool extends the native features of VS code for handling XML files. One important thing it adds is a formatting feature that will make your ProfileXML much easier to manage. The XML Tools plug-in for VS Code can be downloaded here.

XML Formatting

Once the XML Tools plug-in for VS code has been installed, formatting XML for readability is straightforward. Simply right-click anywhere in the document and choose Format Document.

Always On VPN ProfileXML Editing and Formatting with Visual Studio CodeOnce complete, the XML document will be formatted with proper indenting and nesting of elements, as shown here.

Always On VPN ProfileXML Editing and Formatting with Visual Studio CodeSummary

Formatting and syntax must be strictly adhered to when creating a ProfileXML file for Windows 10 Always On VPN. Using Visual Studio Code with the XML Tools plug-in allow the administrator to create and edit XML with proper formatting, which greatly improves readability and allows for streamlined configuration review and troubleshooting.

Acknowledgements

Special thanks to Colin, an avid reader of the articles on this web site for this tip. Thanks, Colin! 🙂

Additional Information

Always On VPN and DirectAccess Scripts and Sample Files on GitHub

Always On VPN IKEv2 Security Configuration

Always On VPN Device Tunnel Step-by-Step Configuration using PowerShell

Always On VPN Hands-On Training Classes in 2019

NetMotion Mobility Device Tunnel Configuration

NetMotion Mobility Device Tunnel ConfigurationIn its default configuration, NetMotion Mobility connections are established at the user level. In most cases this level of access is sufficient, but there are some common uses cases that require VPN connectivity before the user logs on. Examples include provisioning a new device to a user who has never logged on before, or to allow support engineers to connect to a remote device without requiring a user to log in first.

Infrastructure Requirements

To support NetMotion Mobility’s “unattended mode” (device tunnel) it will be necessary to deploy a Windows Server 2016 (or 2012R2) Network Policy Server (NPS). In addition, an internal private certification authority (CA) will be required to issue certificates to the NPS server and all NetMotion Mobility client computers.

Client Certificate Requirements

A certificate with the Client Authentication Enhanced Key Usage (EKU) must be provisioned to the local computer certificate store on all NetMotion Mobility clients that require a device tunnel (figure 1). The subject name on the certificate must match the fully qualified domain name of the client computer (figure 2). It is recommended that certificate auto enrollment be used to streamline the provisioning process.

NetMotion Mobility Device Tunnel Configuration

Figure 1. Computer certificate with Client Authentication EKU.

NetMotion Mobility Device Tunnel Configuration

Figure 2. Computer certificate with subject name matching the client computer’s hostname.

NPS Server Certificate Requirements

A certificate with the Server Authentication EKU must be provisioned to the local computer certificate store on the NPS server (figure 3). The subject name on the certificate must match the fully qualified domain name of the NPS server (figure 4).

NetMotion Mobility Device Tunnel Configuration

Figure 3. Computer certificate with Server Authentication EKU.

NetMotion Mobility Device Tunnel Configuration

Figure 4. Computer certificate with subject name matching the NPS server’s hostname.

NPS Server Configuration

Next install the NPS server role by running the following PowerShell command.

Install-WindowsFeature NPAS -IncludeMamagementTools

Once complete, open the NPS server management console and perform the following steps.

Note: Below is a highly simplified NPS configuration designed for a single use case. It is provided for demonstration purposes only. The NPS server may be used by more than one network access server (NAS) so the example policies included below may not work in every deployment.

  1. Expand RADIUS Clients and Servers.
  2. Right-click RADIUS clients and choose New.
  3. Select the option to Enable this RADIUS client.
  4. Enter a friendly name.
  5. Enter the IP address or hostname of the NetMotion gateway server.
  6. Click Verify to validate the hostname or IP address.
  7. Select Manual to enter a shared secret, or select Generate to create one automatically.
  8. Copy the shared secret as it will be required when configure the NetMotion Mobility gateway server later.
  9. Click OK.
    NetMotion Mobility Device Tunnel Configuration
  10. Expand Policies.
  11. Right-click Network Policies and choose New.
  12. Enter a descriptive name for the new policy.
  13. Select Type of network access server and choose Unspecified.
  14. Click Next.
    NetMotion Mobility Device Tunnel Configuration
  15. Click Add.
  16. Select Client IPv4 Address.
  17. Click Add.
  18. Enter the internal IPv4 address of the NetMotion Mobility gateway server.
  19. Click OK.
  20. Click Next.
    NetMotion Mobility Device Tunnel Configuration
  21. Select Access granted.
  22. Click Next.
    NetMotion Mobility Device Tunnel Configuration
  23. Click Add.
  24. Choose Microsoft: Protected EAP (PEAP).
  25. Click OK.
  26. Select Microsoft: Protected EAP (PEAP).
  27. Click Edit.
  28. Choose the appropriate certificate in the Certificate issued to drop down list.
  29. Select Secure password (EAP-MSCHAP v2).
  30. Click Remove.
  31. Click Add.
  32. Choose Smart Card or other certificate.
  33. Click OK.
  34. Select Smart Card or other certificate.
  35. Click Edit.
  36. Choose the appropriate certificate in the Certificate issued to drop down list.
  37. Click OK.
    NetMotion Mobility Device Tunnel Configuration
  38. Uncheck all options beneath Less secure authentication methods.
  39. Click Next three times.
  40. Click Finish.
    NetMotion Mobility Device Tunnel Configuration

Mobility Server Configuration

Open the NetMotion Mobility management console and perform the following steps.

  1. In the drop-down menu click Configure.
  2. Click Authentication Settings.
  3. Click New.
  4. Enter a descriptive name for the new authentication profile.
  5. Click OK.
  6. Expand Authentication.
  7. Select Mode.
  8. Select Unattended Mode Authentication Setting Override.
  9. From the Authentication mode drop-down box choose Unattended.
  10. Click Apply.
    NetMotion Mobility Device Tunnel Configuration
  11. Expand RADIUS: Device Authentication.
  12. Select Servers.
  13. Select [Profile Name] Authentication Setting Override.
  14. Click Add.
  15. Enter the IP address of the NPS server.
  16. Enter the port (default is 1812).
  17. Enter the shared secret.
  18. Click OK.
    NetMotion Mobility Device Tunnel Configuration
  19. In the drop-down menu click Configure.
  20. Click Client Settings.
  21. Expand Device Settings.
  22. Select the device group to enable unattended mode for.
  23. Expand Authentication.
  24. Select Settings Profile.
  25. Select [Device Group Name] Group Settings Override.
  26. In the Profile drop-down menu choose the authentication profile created previously.
  27. Click Apply.
    NetMotion Mobility Device Tunnel Configuration

Validation Testing

If everything is configured correctly, the NetMotion Mobility client will now indicate that the user and the device have been authenticated.

NetMotion Mobility Device Tunnel Configuration

Summary

Enabling unattended mode with NetMotion Mobility provides feature parity with DirectAccess machine tunnel and Windows 10 Always On VPN device tunnel. It ensures that domain connectivity is available before the user logs on. This allows users to log on remotely without cached credentials. It also allows administrators to continue working seamlessly on a remote computer after a reboot without having a user present to log on.

Additional Resources

NetMotion Mobility as an Alternative to DirectAccess

 

DirectAccess Manage Out with ISATAP and NLB Clustering

DirectAccess Manage Out with ISATAP and NLB ClusteringDirectAccess connections are bidirectional, allowing administrators to remotely connect to clients and manage them when they are out of the office. DirectAccess clients use IPv6 exclusively, so any communication initiated from the internal network to remote DirectAccess clients must also use IPv6. If IPv6 is not deployed natively on the internal network, the Intrasite Automatic Tunnel Addressing Protocol (ISATAP) IPv6 transition technology can be used to enable manage out.

ISATAP Supportability

According to Microsoft’s support guidelines for DirectAccess, using ISATAP for manage out is only supported for single server deployments. ISATAP is not supported when deployed in a multisite or load-balanced environment.

Not supported” is not the same as “doesn’t work” though. For example, ISATAP can easily be deployed in single site DirectAccess deployments where load balancing is provided using Network Load Balancing (NLB).

ISATAP Configuration

To do this, you must first create DNS A resource records for the internal IPv4 address for each DirectAccess server as well as the internal virtual IP address (VIP) assigned to the cluster.

DirectAccess Manage Out with ISATAP and NLB Clustering

Note: Do NOT use the name ISATAP. This name is included in the DNS query block list on most DNS servers and will not resolve unless it is removed. Removing it is not recommended either, as it will result in ALL IPv6-enabled hosts on the network configuring an ISATAP tunnel adapter.

Once the DNS records have been added, you can configure a single computer for manage out by opening an elevated PowerShell command window and running the following command:

Set-NetIsatapConfiguration -State Enabled -Router [ISATAP FQDN] -PassThru

DirectAccess Manage Out with ISATAP and NLB Clustering

Once complete, an ISATAP tunnel adapter network interface with a unicast IPv6 address will appear in the output of ipconfig.exe, as shown here.

DirectAccess Manage Out with ISATAP and NLB Clustering

Running the Get-NetRoute -AddressFamily IPv6 PowerShell command will show routes to the client IPv6 prefixes assigned to each DirectAccess server.

DirectAccess Manage Out with ISATAP and NLB Clustering

Finally, verify network connectivity from the manage out host to the remote DirectAccess client.

Note: There is a known issue with some versions of Windows 10 and Windows Server 2016 that may prevent manage out using ISATAP from working correctly. There’s a simple workaround, however. More details can be found here.

Group Policy Deployment

If you have more than a few systems on which to enable ISATAP manage out, using Active Directory Group Policy Objects (GPOs) to distribute these settings is a much better idea. You can find guidance for creating GPOs for ISATAP manage out here.

DirectAccess Client Firewall Configuration

Simply enabling ISATAP on a server or workstation isn’t all that’s required to perform remote management on DirectAccess clients. The Windows firewall running on the DirectAccess client computer must also be configured to securely allow remote administration traffic from the internal network. Guidance for configuring the Windows firewall on DirectAccess clients for ISATAP manage out can be found here.

ISATAP Manage Out for Multisite and ELB

The configuration guidance in this post will not work if DirectAccess multisite is enabled or external load balancers (ELB) are used. However, ISATAP can still be used. For more information about enabling ISATAP manage out with external load balancers and/or multisite deployments, fill out the form below and I’ll provide you with more details.

Summary

Once ISATAP is enabled for manage out, administrators on the internal network can remotely manage DirectAccess clients wherever they happen to be. Native Windows remote administration tools such as Remote Desktop, Windows Remote Assistance, and the Computer Management MMC can be used to manage remote DirectAccess clients. In addition, enterprise administration tools such as PowerShell remoting and System Center Configuration Manger (SCCM) Remote Control can also be used. Further, third-party remote administration tools such as VNC, TeamViewer, LogMeIn, GoToMyPC, Bomgar, and many others will also work with DirectAccess ISATAP manage out.

Additional Information

ISATAP Recommendations for DirectAccess Deployments

DirectAccess Manage Out with ISATAP Fails on Windows 10 and Windows Server 2016 

DirectAccess Client Firewall Rule Configuration for ISATAP Manage Out

DirectAccess Manage Out and System Center Configuration Manager (SCCM)

Contact Me

Interested in learning more about ISATAP manage out for multisite and external load balancer deployments? Fill out the form below and I’ll get in touch with you.

Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShell

Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShellWindows 10 Always On VPN and DirectAccess both provide seamless, transparent, always on remote network access for Windows clients. However, Always On VPN is provisioned to the user, not the machine as it is with DirectAccess. This presents a challenge for deployment scenarios that require the VPN connection to be established before the user logs on. For example, pre-logon connectivity is required to support remote logon without cached credentials. To address this issue and to provide feature parity with DirectAccess, Microsoft introduced support for a device tunnel configuration option beginning with Windows 10 version 1709 (Fall creators update).

Learn Windows 10 Always On VPN today! Register for an upcoming Always On VPN Hands-On Training class. More details here!

Prerequisites

To support an Always On VPN device tunnel, the client computer must be running Windows 10 Enterprise or Education version 1709 (Fall creators update) or later. It must also be domain-joined and have a computer certificate with the Client Authentication Enhanced Key Usage (EKU) issued by the organization’s Public Key Infrastructure (PKI).

Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShell

In addition, only the built-in Windows VPN client is supported for Always On VPN device tunnel. Although Windows 10 Always On VPN user connections can be configured using various third-party VPN clients, they are not supported for use with the device tunnel.

VPN ProfileXML

The Always On VPN device tunnel is provisioned using an XML file. You can download a sample VPN ProfileXML file here. Make any changes required for your environment such as VPN server hostnames, routes, traffic filters, and remote address ranges. Optionally include the trusted network detection code, if required. Do not change the protocol type or authentication methods, as these are required.

Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShell

Reference: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config#configure-the-vpn-device-tunnel

Once the ProfileXML file is created, it can be deployed using Intune, System Center Configuration Manager (SCCM), or PowerShell. In this post I’ll cover how to configure Windows 10 Always On VPN device tunnel using PowerShell.

Client Configuration

Download the PowerShell script located here and then copy it to the target client computer. The Always On VPN device tunnel must be configured in the context of the local system account. To accomplish this, it will be necessary to use PsExec, one of the PsTools included in the Sysinternals suite of utilities. Download PsExec here, copy it to the target machine, and then run the following command in an elevated PowerShell command window.

PsExec.exe -i -s C:\windows\system32\WindowsPowerShell\v1.0\powershell.exe

Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShell

Another elevated PowerShell window will open, this one now running in the context of the local system account. In this window, navigate to the folder where you copied the PowerShell script and XML file to. Run the PowerShell script and specify the name of the ProfileXML file, as shown below.

VPN_Profile_Device.ps1 -xmlFilePath .\profileXML_device.XML -ProfileName DeviceTunnel

Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShell

To verify creation of the VPN device tunnel, run the following PowerShell command.

Get-VpnConnection -AllUserConnection

Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShell

Note: In Windows 10 releases prior to 1903 the ConnectionStatus will always report Disconnected. This has been fixed in Windows 10 1903.

Server Configuration

If you are using Windows Server 2012 R2 or Windows Server 2016 Routing and Remote Access Service (RRAS) as your VPN server, you must enable machine certificate authentication for VPN connections and define a root certification authority for which incoming VPN connections will be authenticated with. To do this, open an elevated PowerShell command and run the following commands.

$VPNRootCertAuthority = “Common Name of trusted root certification authority”
$RootCACert = (Get-ChildItem -Path cert:LocalMachine\root | Where-Object {$_.Subject -Like “*$VPNRootCertAuthority*” })
Set-VpnAuthProtocol -UserAuthProtocolAccepted Certificate, EAP -RootCertificateNameToAccept $RootCACert -PassThru

Always On VPN Windows 10 Device Tunnel Step-by-Step Configuration using PowerShell

Limitations

Using PowerShell to provision an Always On VPN device tunnel is helpful for initial testing and small pilot deployments, but it does not scale very well. For production deployments it is recommended that Microsoft Intune be used to deploy Always On VPN device tunnel.

Deploy Device Tunnel with Intune

Guidance for deploying an Always On VPN device tunnel using Microsoft Intune can be found here. You can also view the following demonstration video that includes detailed guidance for provisioning the Always On VPN device tunnel using Microsoft Intune.

Summary

Once the Always On VPN device tunnel is configured, the client computer will automatically establish the connection as soon as an active Internet connection is detected. This will enable remote logins for users without cached credentials, and allow administrators to remotely manage Always On VPN clients without requiring a user to be logged on at the time.

Additional Information

Deploy Windows 10 Always On VPN Device Tunnel using Microsoft Intune

VIDEO: Deploying Windows 10 Always On VPN Device Tunnel using Microsoft Intune

Windows 10 Always On VPN Device Tunnel Does Not Connect Automatically

Windows 10 Always On VPN Device Tunnel Does Not Appear in the UI

Windows 10 Always On VPN Hands-On Training

 

 

 

%d bloggers like this: