DirectAccess 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
Jonas
/ June 28, 2018First 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?
Richard M. Hicks
/ July 4, 2018Thanks 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/
Wojciech
/ October 4, 2018Hello 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
Richard M. Hicks
/ October 4, 2018So this is a limitation of the NRPT when configuring an apex domain record. You can include example.net and exclude http://www.example.net, but if a user wants to go to https://example.net it will be tunneled over the DirectAccess connection. No way around that unfortunately.
Zack
/ January 31, 2019Is 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.
Richard M. Hicks
/ January 31, 2019Yes, 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.
Zack
/ February 1, 2019Thanks! I guess with DirectAccess the DA server is functioning as the proxy because of the IPv4 to IPv6 translation?
Richard M. Hicks
/ February 1, 2019Correct. 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. 🙂
Ullef
/ April 18, 2019Thank 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? 🙂
Richard M. Hicks
/ April 18, 2019In 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.
Mark
/ April 23, 2020Hello Richard – love your work I have lurked on your blogs often. I am wanting to deliver a (selective tunnelling) service whereby direct access clients bypass the direct access channel only for a specified list of addresses and treat everything thing else (all other addresses) as internal / get via direct access. Is this possible?
Richard M. Hicks
/ April 24, 2020What you’re looking for is force tunneling with exceptions, which is slightly different than selective tunneling. And, unfortunately, you have no options here. If you enable force tunneling everything comes over the tunnel without exception, and no way to exempt any traffic either.
Stuart
/ April 29, 2020Hi Richard, Do you know if it is possible to configure specific DA clients to use forced tunneling and the rest to use split tunnelling?
I’m guessing how the tunneling configuration works by a group policy setting, if so surely it would be possible to have 2 different group polices for 2 different set of DA clients?
Thanks.
Richard M. Hicks
/ April 29, 2020Routing is not enforced by group policy at all. You can certainly define different routing profiles for different clients, but you would do this by creating different XML configuration files for each connection. One configuration file would have force tunneling enabled, another configuration file would have split tunneling configured. You’d then have to decide how to apply these profiles to each group.
Ray
/ July 21, 2020Hi Richard, given the caveats about the MS browsers, do you know if Selective Tunneling will still work with the updates that were brought to Edge recently? I get timeout errors when traffic is flowing through DA, but works fine if using the Proxy directly (configured in Edge)
Richard M. Hicks
/ July 21, 2020Not sure. I’ve done no testing with this myself.