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.


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 “” domain.

$namespace = “” # 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 = “” # 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 = “” # 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


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

DirectAccess IPv6 Transition Protocols Explained


From a client perspective, DirectAccess is an IPv6-only solution. The DirectAccess client communicates with the DirectAccess server exclusively using IPv6. However, IPv6 is not widely deployed, so the most common scenario will find your DirectAccess clients and servers on the IPv4 Internet.

To facilitate DirectAccess client to server communication with IPv6 when the client is on the IPv4 Internet, IPv6 transition protocols are employed. These protocols effectively tunnel IPv6 packets in IPv4 packets. DirectAccess makes use of three IPv6 transition protocols for client to server connections – 6to4, Teredo, and IP-HTTPS.

DirectAccess Transition Protocols

6to4 – The 6to4 IPv6 transition protocol works by encapsulating IPv6 packets in IPv4 packets using IP protocol 41. 6to4 does not work when the client or the server is behind a NAT, so this IPv6 transition protocol is only used when the client and server are assigned public IPv4 addresses. DirectAccess clients with public IPv4 addresses aren’t common though, and there are some challenges with the stability of 6to4. From experience I can tell you that 6to4 often fails when clients use a cellular Wi-Fi hotspot, for example. For this reason it is generally recommended that you proactively disable this transition protocol to avoid potential issues in the future.

TeredoTeredo is an IPv6 transition protocol that is designed to work when a DirectAccess client (but not the DirectAccess server) is behind a NAT. It works by encapsulating IPv6 packets in IPv4 packets using UDP on port 3544. Teredo will be used any time the DirectAccess client has a private IPv4 address, or when the client has a public IPv4 address and the 6to4 protocol is unavailable (e.g. 6to4 is disabled, or outbound access to IP protocol 41 is restricted by firewall policy). To support Teredo, the DirectAccess server must be configured with two consecutive public IPv4 addresses. In addition, Teredo uses ICMP for NAT detection (e.g. cone, restricted, symmetric), so ICMPv4 echo requests must be allowed inbound to any host with which the DirectAccess client communicates.

IP-HTTPSIP-HTTPS is an IPv6 transition protocol that works by encapsulating IPv6 packets in IPv4 packets using HTTP with SSL/TLS. It is the IPv6 transition protocol of last resort, and will be used any time that 6to4 or Teredo aren’t available. The advantage to using IP-HTTPS is ubiquitous firewall access. Any network with access to the public Internet should, at a minimum, allow outbound HTTP and HTTPS. In some deployment scenarios, IP-HTTPS can be disadvantageous. For example, when Windows 7 DirectAccess clients leverage this IPv6 transition protocol, IPsec-encrypted traffic is encrypted again using SSL/TLS. This double encryption results in high processing overhead and often translates to poor performance and limited scalability. Windows 8 and later clients do not suffer this limitation, as they support null encryption which eliminates the negative effects imposed by double encryption. For the best results using IP-HTTPS, use an application delivery controller to offload SSL, or deploy Windows 8 or later clients. In any case, do not collocate the client-based VPN role on the DirectAccess server, as doing so will remove support for null encryption completely and force even Windows 8 and later clients to perform double encryption for IP-HTTPS traffic.

DirectAccess Server Configuration

To support the 6to4 and Teredo IPv6 transition protocols, the DirectAccess server must be configured with two network interfaces; one internal and one external. The DirectAccess server must have public IPv4 addresses assigned to its external network interface. For Teredo in particular, the DirectAccess server requires two consecutive public IPv4 addresses. Beginning with Windows Server 2012, DirectAccess provides support for DMZ/perimeter network deployment behind a NAT device using RFC1918 private IPv4 addresses with either one or two network interfaces. In this deployment scenario, the DirectAccess server only supports the use of the IP-HTTPS IPv6 transition protocol. 6to4 and Teredo are not available when the DirectAccess server is located behind a NAT device and these IPv6 transition protocols should be disabled on all DirectAccess clients.

DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites

Occasionally I will get a call from a customer that has deployed DirectAccess and is complaining about a security audit finding indicating that the DirectAccess server supports insecure SSL/TLS cipher suites. For example, when using the popular Tenable Nessus vulnerability scanner, a vulnerability report indicates a finding with a Medium severity level in the plug-in “SSL Null Cipher Suites Supported”. The description states that “The remote host supports the use of SSL ciphers that offer no encryption at all.”

DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites

You can confirm this finding by using the Qualys SSL Labs SSL Server Test site. You’ll notice that the test results for a Windows Server 2016 DirectAccess server indicate an overall rating of “F” and a score of “0” for the cipher strength.

DirectAccess IP-HTTPS Insecure SSL and TLS Cipher Suites

Reviewing the details of the test results shows that the following two NULL cipher suites are indeed supported, highlighted below in red.


DirectAccess IP-HTTPS Insecure SSL and TLS Cipher Suites

Note: This doesn’t apply when the client-based VPN or Web Application Proxy (WAP) roles are also installed on the DirectAccess server, or if one-time password (OTP) authentication is enabled.  More details here.

Typically this would be remedied by disabling support for NULL cipher suites using the common SSL and TLS hardening techniques. However, DirectAccess IP-HTTPS is unique in this scenario and the support for NULL cipher suites is by design, so employing traditional SSL and TLS security hardening techniques doesn’t apply here.

This is because DirectAccess IP-HTTPS is only used for IPv6 tunneling purposes, enabling the DirectAccess client that communicates exclusively using IPv6 to connect to the DirectAccess server over the public IPv4 Internet. IPv6 DirectAccess traffic from the client to the server is encrypted with IPsec, so the need for SSL/TLS encryption is not required, and in fact is not desirable for scalability and performance reasons. No unencrypted traffic (with the exception of ICMP) is sent over this SSL/TLS connection.

If a security audit flags support for insecure cipher suites on your Windows Server 2012/R2 DirectAccess server, you can safely ignore it.

%d bloggers like this: