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

Leave a comment

10 Comments

  1. Jonas

     /  June 28, 2018

    First of love your work, you’re life saver!

    What kind of proxy’s would you recommend for selective tunneling?

    You say that only internet explorer and edge is supported. Does that mean that this only support web traffic?

    Reply
    • Thanks Jonas! 🙂 You can use any proxy you like, really. There are many excellent commercial solutions, but I often deploy Squid on Linux as it is open source and free. If you’re not comfortable with Linux there’s a Windows version as well. http://www.squid-cache.org/

      Reply
  2. Wojciech

     /  October 4, 2018

    Hello Richard,

    Following your blog, I have implemented the “selective tunneling” solution in our environment. In general, it seems to work. I do however have one problem, namely with name resolution.

    In my case, I need to route traffic to “domain.com” through our internal network, and at the same time resolve addresses from that domain on the Direct Access server. I have noticed that even if i put “domain.com” in the NRPT table, the DA clients resolve those names on the external DNS servers. Do you know if this can be changed?

    As a workaround, I can explicitly specify hosts in “domain.com” in the NRPT table and have them resolve internally. Though with dozens of hosts, I’m scared that the NRPT table would grow too big and slow down the performance of remote clients.

    Of course if there is no other option, I’ll do it:)

    Kind regards,

    Wojciech

    Reply
  3. Zack

     /  January 31, 2019

    Is there an equivalent to this in Always On VPN? I know there is an NRPT setting in intune but it doesn’t seem to have the same effect that it did in directaccess. Even after putting a domain in the NRPT it still shows as coming from the external IP. It doesn’t seem to get forced through the VPN tunnel.

    I just need a few websites to go through the tunnel for security reasons.

    Reply
    • Yes, but you still have to use a proxy server like you do with DirectAccess. If you simply put the FQDN in the NRPT it will still resolve to an IPv4 address and that will be routed over the Internet, not the VPN. You’ll have to define an on-premises proxy server to force the traffic over the VPN in this case.

      Reply
      • Zack

         /  February 1, 2019

        Thanks! I guess with DirectAccess the DA server is functioning as the proxy because of the IPv4 to IPv6 translation?

      • Correct. When you define a public hostname as internal, it will be resolved by the DNS64 service running on the DirectAccess server. That will return an IPv6 address which will be routed over the DirectAccess connection. 🙂

  4. Ullef

     /  April 18, 2019

    Thank you for as always splendid explanations about DA functionality. I often come to your site for good arcitles to follow. We have a pretty common scenario i guess. We want one specific external host to be routed over the Direct Access tunnel just because that external host is only allow our corporate IP to access their systems. Pretty straightforward yes!

    So, selective tunneling is the solution for this indeed. I dont get the proxy purpose in this case though. When we try to access the external host on the DA-server it-self it works flawless because our Corporate IP (outside firewall IP). If we tunnel this external host via DA the same thing should happen correct?

    Maybe i am miss understanding something here. But if the external host can be accessed from the DA-server then it should also be accesed via clients that are connected to DA yes? I have of course put the external host in NRPT and both suffix and DNS are entered so it shoud go through the tunnel.

    In my mind no separate proxy (exept for the DA-server itself) should be needed in our case, or what am i not getting? 🙂

    Reply
    • In theory, yes. In practice, the translation from IPv6 to IPv4 complicates things. That’s where the real problem lies, and that’s why you typically need an on-premises proxy for this to work. You can certainly try it without one though. If it works, great. If not, you’ll most likely need to set up a proxy.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: