Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Microsoft Intune NDES Connector Setup Wizard Ended PrematurelyA Windows Server with the Network Device Enrollment Service (NDES) role can be provisioned on-premises to support certificate deployment for non-domain Windows 10 Always On VPN clients. In addition, the Microsoft Intune Connector must be installed and configured on the NDES server to allow Intune-managed clients to request and receive certificates from the on-premises Certification Authority (CA) server.

Setup Wizard Ended Prematurely

When installing the Microsoft Intune Connector, the administrator may encounter a scenario where the setup wizard fails with the following error message.

“Microsoft Intune Connector Setup Wizard ended prematurely because of an error. Your system has not been modified. To install this program at a later time, run Setup Wizard again. Click the Finish button to exit the Setup Wizard.”

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Cryptographic Service Provider

This error can occur if the NDES server certificate template is configured to use the Key Storage Provider cryptography service provider (CSP). When configuring the certificate template for the NDES server, the Legacy Cryptography Service Provider must be used, as shown here.

Microsoft Intune NDES Connector Setup Wizard Ended Prematurely

Additional Information

Deploying Windows 10 Always On VPN with Intune using Custom ProfileXML

Windows 10 Always On VPN Device Tunnel Configuration using Microsoft Intune

Deploying Windows 10 Always On VPN with Microsoft Intune

 

Troubleshooting Always On VPN Error Code 864

When configuring an Always On VPN connection, the administrator may encounter a scenario in which a VPN connection fails using either Internet Key Exchange version 2 (IKEv2) or Secure Socket Tunneling Protocol (SSTP). On the Windows 10 client the error message states the following.

“Can’t connect to [connection name]. The remote access connection completed, but authentication failed because a certificate that validates the server certificate was not found in the Trusted Root Certification Authorities certificate store.”

Troubleshooting Always On VPN Error Code 864

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

“The user [username] dialed a connection name [connection name] which has failed. The error code returned on failure is 864.”

Troubleshooting Always On VPN Error Code 864

NPS Server Certificate

Error code 864 is commonly caused by a missing or invalid server certificate on the Network Policy Server (NPS) performing authentication for VPN clients. The NPS server must have a certificate installed in its local computer certificate store from a trusted certification authority (CA) that includes the following.

Subject Name

The subject name must match the hostname defined in the EAP configuration for VPN clients. This may be the NPS server’s hostname but could also be an alias when NPS load balancing is configured.

Troubleshooting Always On VPN Error Code 864

Enhanced Key Usage

The NPS server certificate must include the Server Authentication Enhanced Key Usage (EKU).

Troubleshooting Always On VPN Error Code 864

NPS Policy Configuration

The NPS server certificate must also be selected in the network policy used for VPN client authentication. To confirm correct certificate configuration, open the properties for the Always On VPN network policy and follow the steps below.

1. Select the Constraints tab.
2. Highlight Authentication Methods.
3. Highlight Microsoft: Protected EAP (PEAP) in the EAP Types field.
4. Click Edit.
5. Select the NPS server certificate from the Certificate issued to drop-down list.

Troubleshooting Always On VPN Error Code 864

Ensure the NPS server certificate is also used for client certificate authentication by performing the following steps.

1. Highlight Smart Card or other certificate.
2. Click Edit.
3. Select the NPS server certificate from the Certificate issued to drop-down list.
4. Click Ok.

Troubleshooting Always On VPN Error Code 864

Additional Information

Windows 10 Always On VPN Network Policy Server (NPS) Load Balancing

Always On VPN Load Balancing for RRAS in Azure

Always On VPN Load Balancing for RRAS in AzurePreviously I wrote about Always On VPN options for Microsoft Azure deployments. In that post I indicated that running Windows Server with the Routing and Remote Access Service (RRAS) role for VPN was an option to be considered, even though it is not a formally supported workload. Despite the lack of support by Microsoft, deploying RRAS in Azure works well and is quite popular. In fact, I recently published some configuration guidance for RRAS in Azure.

Load Balancing Options for RRAS

Multiple RRAS servers can be deployed in Azure to provide failover/redundancy or to increase capacity. While Windows Network Load Balancing (NLB) can be used on-premises for RRAS load balancing, NLB is not supported and doesn’t work in Azure. With that, there are several options for load balancing RRAS in Azure. They include DNS round robin, Azure Traffic Manager, the native Azure load balancer, Azure Application Gateway, or a dedicated load balancing virtual appliance.

DNS Round Robin

The easiest way to provide load balancing for RRAS in Azure is to use round robin DNS. However, using this method has some serious limitations. Simple DNS round robin can lead to connection attempts to a server that is offline. In addition, this method doesn’t accurately balance the load and often results in uneven distribution of client connections.

Azure Traffic Manager

Using Azure Traffic Manager is another alternative for load balancing RRAS in Azure. In this scenario each VPN server will have its own public IP address and FQDN for which Azure Traffic Manager will intelligently distribute traffic. Details on configuring Azure Traffic Manager for Always On VPN can be found here.

Azure Load Balancer

The native Azure load balancer can be configured to provide load balancing for RRAS in Azure. However, it has some serious limitations. Consider the following.

  • Supports Secure Socket Tunneling Protocol (SSTP) only.
  • Basic health check functionality (port probe only).
  • Limited visibility.
  • Does not work with IKEv2.
  • Does not support TLS offload for SSTP.

More information about the Azure Load Balancer can be found here.

Azure Application Gateway

The Azure Application Gateway can be used for load balancing RRAS SSTP VPN connections where advanced capabilities such as enhanced health checks and TLS offload are required. More information about the Azure Application Gateway can be found here.

Load Balancing Appliance

Using a dedicated Application Delivery Controller (ADC), or load balancer is a very effective way to eliminate single points of failure for Always On VPN deployments hosted in Azure. ADCs provide many advanced features and capabilities to ensure full support for all RRAS VPN protocols. In addition, ADCs offer much better visibility and granular control over VPN connections. There are many solutions available as virtual appliances in the Azure marketplace that can be deployed to provide RRAS load balancing in Azure.

Summary

Deploying Windows Server RRAS in Azure for Always On VPN can be a cost-effective solution for many organizations. Although not a formally supported workload, I’ve deployed it numerous times and it works quite well. Consider using a dedicated ADC to increase scalability or provide failover and redundancy for RRAS in Azure whenever possible.

Additional Information

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN and RRAS in Microsoft Azure

Windows 10 Always On VPN with Microsoft Azure Gateway

Always On VPN and RRAS with Single NIC

Always On VPN and RRAS with Single NICI’m commonly asked “can Windows Server with Routing and Remote Access Service (RRAS) be configured with a single network interface?” This is likely because the official Microsoft documentation references only a multihomed dual NIC configuration, leading many to believe it is a strict requirement.

Single NIC

Deploying Windows Server RRAS with a single network interface is indeed supported and works without issue. There are no functional limitations imposed by using a single network interface. All features are fully supported in this scenario. The choice to use one or two network interfaces is purely a design choice, driven by several factors such as current network configuration and security requirements.

Dual NIC

Although a single NIC configuration is fully supported, there are some important advantages associated with mulithome dual NIC deployments. The following should be considered when deciding between single NIC and dual NIC VPN configurations.

Traffic Segmentation

Having separate internal and external network connections provides logical and physical separation of trusted and untrusted network traffic. Terminating connections from Always On VPN clients on the Internet in an isolated perimeter or DMZ network yields positive security benefits.

Firewall Configuration

Using two network interfaces allows for a more restrictive Windows Firewall policy to be applied to the external interface. This reduces the exposure of running services on the RRAS server to untrusted networks. This is especially critical if the VPN server is Windows Server RRAS and it is joined to a domain.

Network Performance

For very busy RRAS servers, having two network interfaces can improve network performance. With two network interfaces, network traffic is distributed between two network adapters, reducing utilization on each interface.

Dual NIC Best Practices

When deploying an RRAS server with dual NICs, the following recommendations for network interface configuration should be followed.

IP Addressing

Each network interface must be assigned an IP address from a unique subnet. Having both NICs on the same subnet is not supported.

Default Gateway

The default gateway should be configured on the external facing network interface only. The internal interface should not be configured with a gateway. Rather, static routes to any remote internal networks should be configured.

To add a static route on a Windows Server, open an elevated PowerShell command window and run the following command.

New-NetRoute -AddressFamily IPv4 -DestinationPrefix 10.0.0.0/8 -InterfaceAlias ‘Internal’ -NextHop 172.21.12.254

DNS

For domain-joined RRAS servers, corporate DNS servers should be configured on the Internal network interface only. No DNS servers should be configured on the external interface. If the server is not joined to a domain, DNS servers can be configured on whichever interface has connectivity to the defined DNS servers.

NAT

When the RRAS server is behind a device performing Network Address Translation (NAT), the NAT should be configured to translate only the destination address (DNAT). This allows the VPN server (or load balancer for multiserver deployments) to see the client’s original source IP address, which ensures efficient traffic distribution and meaningful log data.

Client, Service, and Protocol Bindings

All unnecessary clients, services, and protocols should be unbound from the external network interface. It is recommended that only the IPv4 and IPv6 protocols be enabled on the external interface, as shown here. Again, this reduces exposure for the server to the untrusted external network.

Always On VPN and RRAS with Single NIC

Summary

The dual NIC, multihomed configuration is generally recommended for most deployments as it offers security and performance advantages over the single NIC configuration. For organizations with less demanding security requirements, a single NIC deployment can be deployed safely without compromising functionality or supportability. In addition, a single NIC deployment may be the best option when multiple networks aren’t readily available.

Additional Information

Windows 10 Always On VPN and Windows Server Routing and Remote Access (RRAS)

Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN Hands On Training

Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

Always On VPN Clients Prompted for Authentication when Accessing Internal ResourcesWhen deploying Windows 10 Always On VPN using Protected Extensible Authentication Protocol (PEAP) with client authentication certificates, the administrator may encounter a scenario in which the user can establish a VPN connection without issue, but when accessing internal resources they are prompted for credentials and receive the following error message.

“The system cannot contact a domain controller to service the authentication request. Please try again later.”

Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

Resolution

This can occur if one or more domain controllers in the enterprise have expired or missing domain controller authentication certificates. To ensure seamless single sign-on to internal resources, ensure that all domain controllers have a certificate issued by the internal certification authority (CA) that includes the Server Authentication (1.3.6.1.5.5.7.3.1), Client Authentication (1.3.6.1.5.5.7.3.2), KDC Authentication (1.3.6.1.5.2.3.5), and Smart Card Logon (1.3.6.1.4.1.311.20.2.2) Enhanced Key Usage (EKU). Administrators can duplicate the Kerberos Authentication template for this purpose.

Always On VPN Clients Prompted for Authentication when Accessing Internal Resources

Additional Information

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Hands-On Training

 

Always On VPN SSTP Connects then Disconnects

Always On VPN SSTP Connects then DisconnectsWhen Always On VPN clients are configured to use the Secure Socket Tunneling Protocol (SSTP) with Windows Server Routing and Remote Access Service (RRAS), administrators may encounter a scenario in which a client can establish a VPN connection using SSTP successfully, but is then disconnected immediately. The system event log contains an entry with Event ID 6 from the RasSstp source that includes the following error message.

“The SSTP-based VPN connection to the remote access server was terminated because of a security check failure. Security settings on the remote access server do not match settings on this computer. Contact the system administrator of the remote access server and relay the following information.”

Always On VPN Connect and Disconnect with SSTP

Common Causes

The two most common causes of this issue are when SSTP is configured for SSL offload, and when a VPN client is on a network where SSL inspection is taking place.

SSTP Offload

The most common cause of this issue is when SSL offload is configured for SSTP on an external load balancer or application delivery controller (ADC). To prevent interception from a Man-in-the-Middle attack, the VPN client sends the certificate hash of the SSL certificate used when the VPN connection was established. If this information does not match what is configured on the RRAS server, the connection is assumed to be compromised and the connection is immediately dropped.

SSL Inspection

Another scenario where this issue may occur is when a VPN client is behind a network device configured to perform SSL deep-packet inspection (DPI). SSTP VPN clients will be unable to connect to the VPN server in this scenario.

Resolution

When offloading SSL to another device, the RRAS server must be configured to know which SSL certificate is being presented to remote clients. This information is stored in the following registry key.

HKLM:\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters\SHA256CertificateHash

However, this registry entry requires a binary value, which makes it a challenge to configure manually. To resolve this problem, it is recommended that the same SSL certificate installed on the load balancer/ADC also be installed on the VPN server (even though SSL will be offloaded). To do this, first import the SSL certificate and private key in to the Local Computer certificate store, then open the RRAS management console and perform the following steps.

  1. Right-click the VPN server and choose Properties.
  2. Select the Security tab.
  3. Uncheck Use HTTP in the SSL Certificate Binding section.
  4. Select the appropriate SSL certificate from the Certificate drop-down list (click View to verify).
  5. Click Apply.

This will add the correct SSL certificate information to the registry. Next, re-enable HTTP for SSL offload by performing the following steps.

  1. Check Use HTTP in the SSL Certificate Binding section.
  2. Click Apply.

PowerShell Configuration

If the SSL certificate cannot be installed on the VPN server, or to automate this configuration across multiple servers remotely, download and run the Enable-SstpOffload PowerShell script from my GitHub repository here and run the following command.

Enable-SSTPOffload -CertificateHash [SHA256 Certificate Hash of Public SSL Certificate] -Restart

For example…

Enable-SSTPOffload -CertificateHash “C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2” -Restart

Additional Information

Windows 10 Always On VPN Load Balancing and SSL Offload

Windows 10 Always On VPN SSTP Load Balancing with F5 BIG-IP

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS

 

Always On VPN SSTP Load Balancing and SSL Offload

SSL Certificate Considerations for DirectAccess IP-HTTPSThe Windows Server Routing and Remote Access Service (RRAS) is a popular choice for a VPN server to support Windows 10 Always On VPN deployments. One significant advantage RRAS provides is support for the Secure Socket Tunneling Protocol (SSTP). SSTP is a Microsoft proprietary VPN protocol that uses Transport Layer Security (TLS) to ensure privacy between the VPN client and server. The advantage to using a TLS-based transport is that it leverages the standard HTTPS TCP port 443, making it firewall friendly and ensuring ubiquitous remote access even behind highly restrictive firewalls.

Load Balancing SSTP

Load balancing SSTP can be accomplished in much the same way as a load balancing a common web server using HTTPS. The external load balancer is configured with a virtual IP address (VIP) and each VPN server is configured behind it. Session persistence should be configured to use SSL with source IP address persistence as a fallback.

SSL Offload for SSTP

In most cases, simply forwarding encrypted SSTP connections to the VPN server will be sufficient. However, offloading SSL/TLS processing to an Application Delivery Controller (ADC) or load balancer can be beneficial for the following reasons.

Resource Utilization

Enabling TLS offload for SSTP VPN connections can reduce CPU and memory utilization on the VPN server. However, this will likely only be necessary for very busy servers supporting many concurrent connections.

Security

In some cases, the administrator may not be able to install the public SSL certificate on the VPN server. For example, a security policy may exist that restricts SSL certificate installation to dedicated security devices using a Hardware Security Module (HSM). In some cases, it may be desirable to restrict access to high value certificates such as wildcard certificates.

Certificate Management

Often SSL certificates are implemented on load balancers to reduce certificate sprawl and to ease the management and administration burden in the enterprise. By having all enterprise certificates installed only on dedicated security devices, administrators can more effectively monitor and manage SSL certificate lifecycles.

SSTP Configuration for TLS Offload

Configuration changes must be made on the load balancer and the RRAS server to support TLS offload for SSTP.

Load Balancer

Install the public SSL certificate on the load balancer and configure it for TLS termination. Configure the load balancer to then use HTTP for backend server connections. Consult the load balancer vendor’s documentation for configuration guidance.

Load Balancing Always On VPN SSTP Load Balancing with F5 BIG-IP

RRAS Server

If the public SSL certificate is installed on the VPN server, enabling TLS offload for SSTP is simple and straightforward. Follow the steps below to enable TLS offload for SSTP VPN connections.

  1. Open the RRAS management console (rrasmgmt.msc).
  2. Right-click the VPN server and choose Properties.
  3. Select the Security tab.
  4. Check Use HTTP in the SSL Certificate Binding section.
  5. Click Ok and then Yes to restart the Remote Access service.

Always On VPN SSTP Load Balancing and SSL Offload

If the public SSL certificate is not or cannot be installed on the RRAS server, additional configuration will be required. Specifically, SSL offload for SSTP must be configured using the Enable-SSTPOffload PowerShell script, which can be downloaded here.

Once the script has been downloaded and imported, open an elevated PowerShell command window and enter the following command.

Enable-SSTPOffload -CertificateHash [SHA256 Certificate Hash of Public SSL Certificate] -Restart

For example…

Enable-SSTPOffload -CertificateHash “C3AB8FF13720E8AD9047DD39466B3C8974E592C2FA383D4A3960714CAEF0C4F2” -Restart

Re-Encryption

When offloading TLS for SSTP VPN connections, all traffic between the load balancer and the VPN server will be sent in the clear using HTTP. In some scenarios, TLS offload is required only for traffic inspection, not performance gain. When terminating TLS on the load balancer and re-encrypting connections to the VPN server is required, it is only supported if the same certificate is used on both the load balancer and the VPN server.

Additional Information

Windows 10 Always On VPN SSL Certificate Requirements for SSTP

Windows 10 Always On VPN SSL Load Balancing with F5 BIG-IP

Windows 10 Always On VPN IKEv2 and SSTP Fallback

Windows 10 Always On VPN Hands-On Training Classes for 2019

 

Always On VPN and Third Party VPN Devices

Always On VPN and Third Party VPN DevicesOne of the most important advantages Windows 10 Always On VPN has over DirectAccess is infrastructure independence. That is, Always On VPN does not rely exclusively on a Windows Server infrastructure to support Always On VPN connections. Always On VPN will work with many third-party firewalls and VPN devices, as long as they meet some basic requirements.

Advantages

Third-party firewalls or VPN devices offer some important advantages over Windows Servers running the Routing and Remote Access Services (RRAS), both in terms of security and performance.

Security

Dedicated security devices (physical or virtual) provide better security than a common Windows server. They commonly run specialized, security-hardened operating systems that are highly secure and resistant to attack. In addition, these solutions typically allow the administrator to define policy to restrict access to internal resources and do so in a centralized way. This is often easier to implement and manage than using traffic filters on the client side. They often include advanced security features such as URL filtering and malware inspection to better protect remote clients. Some solutions include Hardware Security Module (HSM) integration to further enhance security.

Performance

Purpose-built solutions often provide better throughput and performance than do Windows Servers by virtue of their proprietary operating systems. This allows for better network throughput and the ability to support many more connections per device.

Disadvantages

The main drawbacks for using a third-party device are cost and administrative overhead. Third-party solutions must be acquired, for which there is typically a non-trivial cost associated. They often need additional per-user licensing. In addition, many of these solutions require specialized skill sets to implement, manage, and support which could further increase the overall cost of the solution.

Interoperability Requirements

Any firewall or VPN device can be used for Always On VPN as long as they support the Internet Key Exchange version 2 (IKEv2) VPN protocol for remote access connections. Most modern firewalls today support IKEv2, but some (such as the Sophos XG firewall) do not. Check with your vendor to validate support.

Native Client

If the firewall or VPN device supports IKEv2 for remote access connections, the native Windows VPN provider can be used to establish an Always On VPN connection. The native provider is used when the Always On VPN ProfileXML is configured using the NativeProfile element.

Plug-In VPN Client

One crucial drawback to using IKEv2 is that it is commonly blocked by firewalls. Many third-party VPN vendors offer a plug-in client that enables support for TLS-based transport, which is more firewall friendly than IKEv2. Plug-in VPN providers are available in the Microsoft store.

Below is a current list of available third-party VPN plug-in providers for Windows 10. (Updated April 5 to now include Cisco AnyConnect!)

  • Check Point Capsule
  • Cisco AnyConnect
  • F5 Access
  • Fortinet Forticlient
  • Palo Alto GlobalProtect
  • Pulse Secure
  • SonicWall Mobile Connect

Always On VPN and Third-Party VPN Devices

Note: Win32 VPN client applications from third-party vendors are not supported with Windows 10 Always On VPN.

Additional Information

What is the Difference Between DirectAccess and Always On VPN?

5 Things DirectAccess Administrators Should Know about Always On VPN

3 Important Advantages of Always On VPN over DirectAccess

Always On VPN IKEv2 and SSTP Fallback

Always On VPN IKEv2 and SSTP FallbackA while back I wrote about the various VPN protocols supported for Windows 10 Always On VPN. The two most common are Internet Key Exchange version 2 (IKEv2) and Secure Socket Tunneling Protocol (SSTP). The article covers in detail each protocol’s advantages and disadvantages. To summarize, IKEv2 provides the best security (when configured correctly!) and SSTP is firewall-friendly ensuring ubiquitous access. Ideally an Always On VPN connection will attempt to use the more secure IKEv2 first, then fallback to SSTP only when IKEv2 is unavailable. Unfortunately, Always On VPN connections do not work this way today.

IKEv2 and SSTP

IKEv2 and SSTP are not mutually exclusive. When using Windows Routing and Remote Access Service (RRAS) as the VPN server, both protocols can be configured and enabled for VPN clients. To allow VPN clients to automatically select a protocol, the NativeProtocolType element in ProfileXML can be set to Automatic.

Always On VPN IKEv2 and SSTP Fallback

IKEv2 with SSTP Fallback?

In theory, with the NativeProtocolType set to Automatic, the Windows 10 client would first attempt to establish an IKEv2 connection, then fall back to SSTP if IKEv2 is not available. In practice, this is not the case.

SSTP Preferred over IKEv2

In operation, setting the NativeProtocolType to Automatic results in the Windows 10 client attempting to establish a VPN connection using SSTP first! If the SSTP connection fails, only then will IKEv2 be used. The only scenario in which I can imagine SSTP failing and IKEv2 being successful would be if SSTP is not supported by the VPN server. Sadly, this scenario may result in failed connections due to a bug in the way ProfileXML settings are processed. Details here.

VPN Strategy

The initial VPN protocol selection behavior is dictated by the VpnStrategy setting of the Always On VPN connection in the rasphone.pbk file. This file can be found under C:\Users\[username]\AppData\Roaming\Microsoft\Network\Connections\Pbk. The documentation on the Microsoft website is terribly outdated and does not include the following important VpnStrategy settings pertinent to Windows 10 Always On VPN connections.

  • 5 = Only SSTP is attempted
  • 6 = SSTP is attempted first
  • 7 = Only IKEv2 is attempted
  • 8 = IKEv2 is attempted first
  • 14 = IKEv2 is attempted followed by SSTP

Always On VPN Default Behavior

For Always On VPN, when the NativeProtocolType is set to Automatic in ProfileXML, VpnStrategy is set to 6 by default, which means the connection will attempt to use SSTP first. If it fails, IKEv2 will be attempted.

Always On VPN IKEv2 and SSTP Fallback

If the NativeProtocolType in ProfileXML is set to IKEv2, VpnStrategy is set to 7 and only IKEv2 is used. A connection using SSTP is never attempted.

Workaround

Setting the VpnStrategy to 8 or 14 will force the client to attempt an IKEv2 connection first. However, this setting is dynamically updated by Windows and is subject to change. For example, if an IKEv2 connection fails and SSTP is successful, Windows will then set the VpnStrategy to 6 and all subsequent VPN connection attempts will use SSTP first. Because of this it will be necessary to update the VpnStrategy setting each time prior to establishing a VPN connection. This will require some clever scripting and perhaps automation using a scheduled task based on an event trigger. I will leave that custom configuration as an exercise for the reader. If you’ve developed something to address this challenge, please feel free to share in the comments below. 🙂

Additional Information

Always On VPN Protocol Recommendations for Windows Server RRAS

Always On VPN IKEv2 Security Configuration

Always On VPN Certificate Requirements for IKEv2

Always On VPN IKEv2 Load Balancing with KEMP LoadMaster Load Balancer

DirectAccess Selective Tunneling

DirectAccess Selective TunnelingDirectAccess administrators, and network administrators in general, are likely familiar with the terms “split tunneling” and “force tunneling”. They dictate how traffic is handled when a DirectAccess (or VPN) connection is established by a client. Split tunneling routes only traffic destined for the internal network over the DirectAccess connection; all other traffic is routed directly over the Internet. Force tunneling routes all traffic over the DirectAccess connection.

Force Tunneling

DirectAccess uses split tunneling by default. Optionally, it can be configured to use force tunneling if required. Force tunneling is commonly enabled when DirectAccess administrators want to inspect and monitor Internet traffic from field-based clients.

Note: One-time password user authentication is not supported when force tunneling is enabled. Details here.

Drawbacks

Force tunneling is not without its drawbacks. It requires that an on-premises proxy server be used by DirectAccess clients to access the Internet, in most cases. In addition, the user experience is often poor when force tunneling is enabled. This is caused by routing Internet traffic, which is commonly encrypted, over an already encrypted connection. The added protocol overhead caused by double encryption (triple encryption if you are using Windows 7!) along with using a sub-optimal network path increases latency and can degrade performance significantly. Also, location-based services typically fail to work correctly.

Selective Tunneling

“Selective Tunneling” is a term that I commonly use to describe a configuration where only one or a few specific public resources are tunneled over the DirectAccess connection. A common use case is where access to a cloud-based application is restricted to the IP address of a corporate proxy or firewall.

Using the Name Resolution Policy Table (NRPT) and taking advantage of DirectAccess and its requirement for IPv6, DirectAccess administrators can choose to selectively route requests for public hosts or domains over the DirectAccess connection. The process involves defining the public Fully Qualified Domain Name (FQDN) as “internal” in the DirectAccess configuration and then assigning an on-premises proxy server for DirectAccess clients to use to access that namespace.

Enable Selective Tunneling

While some of the selective tunneling configuration can be performed using the Remote Access Management console, some of it can only be done using PowerShell. For this reason, I prefer to do everything in PowerShell to streamline the process.

Run the following PowerShell commands on the DirectAccess server to enable selective tunneling for the “.example.com” domain.

$namespace = “.example.com” # include preceding dot for namespace, omit for individual host
$dnsserver = Get-ItemPropertyValue –Path HKLM:\\SYSTEM\CurrentControlSet\Services\RaMgmtSvc\Config\Parameters -Name DnsServers

Add-DAClientDnsConfiguration -DnsSuffix $namespace -DnsIpAddress $dnsserver -PassThru

$gpo = (Get-RemoteAccess).ClientGpoName
$gpo = $gpo.Split(‘\’)[1]
$proxy = “proxy.corp.example.net:8080” # this is the FQDN and port for the internal proxy server
$rule = (Get-DnsClientNrptRule -GpoName $gpo | Where-Object Namespace -eq $namespace | Select-Object -ExpandProperty “Name”)

Set-DnsClientNrptRule -DAEnable $true -DAProxyServerName $proxy -DAProxyType “UseProxyName” -Name $rule -GpoName $gpo

If Windows 7 client support has been enabled, run the following PowerShell commands on the DirectAccess server. If multisite is enabled, run these commands on one DirectAccess server in each entry point.

$downlevelgpo = (Get-RemoteAccess).DownlevelGpoName
$downlevelgpo = $downlevelgpo.Split(‘\’)[1]
$proxy = “proxy.corp.example.net:8080” # this is the FQDN and port for the internal proxy server
$downlevelrule = (Get-DnsClientNrptRule -GpoName $downlevelgpo | Where-Object Namespace -eq $namespace | Select-Object -ExpandProperty “Name”)

Set-DnsClientNrptRule -DAEnable $true -DAProxyServerName $proxy -DAProxyType “UseProxyName” -Name $downlevelrule -GpoName $downlevelgpo

To remove a namespace from the NRPT, run the following PowerShell command.

Remove-DAClientDnsConfiguration -DnsSuffix $namespace

Caveats

While selective tunneling works well for the most part, the real drawback is that only Microsoft browsers (Internet Explorer and Edge) are supported. Web sites configured for selective tunneling will not be reachable when using Chrome, Firefox, or any other third-party web browser. In addition, many web sites deliver content using more than one FQDN, which may cause some web pages to load improperly.

Additional Resources

DirectAccess Force Tunneling and Proxy Server Configuration

NetMotion Mobility for DirectAccess Administrators – Split vs. Force Tunneling

%d bloggers like this: