Why Split Tunneling is Not a Security Issue with DirectAccess

(Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag)

As a member of the Anywhere Access Team with a primary focus on UAG DirectAccess (DA), one of the questions that I hear a lot relates to the security of the solution, due to the fact that split tunneling is enabled by default.

If you’re a VPN guy, you are probably aware of the issue of split tunneling. When split tunneling is disabled, the VPN client uses the VPN gateway as its default gateway, so that all off subnet communications must go through the VPN gateway. It also prevents the the VPN clients from potentially routing communications between two networks, such as the client’s network and the corporate network.

For this reason, most experienced VPN admins disable split tunneling by default. This has become a habit for VPN admins and they don’t think twice about it. However, what they gain in security is lost in performance for the corporate Internet connection.

The reason for this is that the VPN client must go through the VPN gateway to access Internet content, so that the request/response path for Internet content is from the VPN client, to the VPN gateway, to an Internet gateway on the corpnet, to the Internet, and then the response is returned using the same path in the opposite direction.

As you can imagine, if you have more than a few VPN clients, this could become a major bottleneck on your Internet bandwidth.

The DA team understands this problem very well. If the DA client connection isn’t highly performant, users will likely be unsatisfied with the solution. The productivity gains you expected will evaporate, as users won’t use DA to connect to the corpnet, and they’ll return to their old inefficient ways of working.

So, DirectAccess by default enables split tunneling. All traffic destined to the corpnet is sent over the DA IPsec tunnels, and all traffic destined for the Internet is sent directly to the Internet over the local interface. This prevents DA clients from bringing the corporate Internet connection to its knees.

However, it has left the issue of potential risks of split tunneling in the minds of admins who are considering DA. One option is to use “force tunneling”. You can find out more about force tunneling at http://technet.microsoft.com/en-us/library/dd637812(WS.10).aspx One of the primary disadvantages of force tunneling is reduced performance, especially in the context of reaching IPv4 only resources.

But this begs the question: is DA split tunneling really a problem? The answer is no.

Why? Because the risks that exist with VPNs, where the machine can act as a router between the Internet and the corporate network is  not valid with DirectAccess. IPsec rules on the UAG server require that traffic be from an authenticated source, and all traffic between the DA client and server is protected with IPsec.

Thus, in the scenario where the DA client might be configured as a router, the source of the traffic isn’t going to be the DA client, and authentication will fail – hence preventing the type of routing that VPN admins are concerned about.



Tom Shinder
Microsoft ISDUA
Anywhere Access Team/UAG DirectAccess

Bookmark and Share

Comments (17)
  1. Anonymous says:

    Ken – regarding NAC and a compromised laptop – that goes back to my SSL inspection issue. IDS is going to see an SSL session and that's it. And suppose the connection goes to a hijacked site, so web filtering doesn't catch it. I can think of many other similar scenarios for hosts on the intranet.



  2. Anonymous says:

    @Patrick –

    Good observation 🙂

    And that feeds back into my last comment regarding always being under the control of an Internet filtering solution.

    That's the attraction of Force Tunneling – since the connection will always go through the DA tunnels, you can always direct the traffic through the corpnet filtering solution.

    But there are other ways you can solve this problem – such as cloud based web anti-malware and URL filtering solutions.



  3. Anonymous says:

    @Ken –

    That is a realistic scenario – but the DA machine is always managed and always up to date, just like the traditional corpnet machine.

    What happens in the same situation to a machine with the same compromise, but without DirectAccess, and it brought into the corpnet the next day when the employee comes to work?



  4. Anonymous says:

    Hi Adrian,

    Thanks for commenting! Yes, the DA client is not immune to attacks and I didn’t want to give that impression. However, the DA client is a "fully managed" client, does not fall outside of your organizations desired configuration and security requirements, and is arguably as secure as than other host on the corporate network. I agree that with Win7 being a requirement, it makes the entire solution only that much stronger from a security perspective. Looks forward to hearing more of you ideas in this area.



  5. Anonymous says:


    Exactly – what is the difference?

    There is only one difference that I can see, and it could be considered an important one, if you assume that corpnet machines *never leave the corpnet* – if you assume that corpnet machines never leave the corpnet, we can assume that they are exposed to the corp firewall so that web antimalware and URL filtering is in place to reduce the risk of compromise from an Internet host.

    But does that "corpnet only" host actually exist? Most firms give employees laptops that move onto and out of the corpnet – even if the moving "onto" the network is over a VPN connection and not a physical connection.

    Ideally, the DirectAccess client (and all clients actually) would always be forced through a anti-malware and URL filtering device regardless of location. That would bring the DA client (and any client that ever leaves the corpnet) more in line with the classical "bolted in" corpnet computer.



  6. Anonymous says:

    Hi Povl,

    IPv6 on the internal corpnet is not required for DirectAccess. You can have an all IPv4 network and DirectAccess will work very well. So, if you think IPv6 is a requirement for DA and is blocking you – understand that it is not and that you can deploy DirectAccess on your IPv4 network now.



  7. Anonymous says:

    Hi Ken,

    That is true – but at some point I think we need to move away from "it's possible that Martians will come to Earth and give us cold fusion and then leave in peace" approach to security. 🙂

    I can come up with equally unlikely, *but possible* compromises for clients that are on the intranet – heck, anyone who doesn't do outbound SSL inspection is essentially in a potential "split tunneling" scenario.

    The key is to weigh the net productivity gain against the likelihood that a certain compromise on a DirectAccess client will be any different that a client on the intranet. And I think the primary point to take home is not that the DirectAccess client is more secure, but just as secure as an "intranet" client, because that intranet client moves on and off the network and modern malware is very comfortable about waiting for an oppotuntity to do what it wants to do.

    As the recent wikileaks event has taught us – it's the insider threats now that are our biggest security concern.

    Great conversation!



  8. Anonymous says:

    I agree and respectfully disagree in the same time. 🙂

    DirectAccess can be the subject of pivot attacks, either directed ones, or sideway ones. Same is true for traditional VPNs(it does not matter if they disable or not split tunneling or not, or "control" it at the gateway level-nice myth-).

    I wanted for a while to wrote something and bring the split tunneling thing into the Web 2.0/modern era, but did not have time for this.

    Routing, what routing ? 😉

    One strength of DirectAccess is that it runs on the client side on Windows 7, the most secure OS to date(this kinda stands in the way of the pivot attacks, if I will manage to finish writing my paper, I might come with some examples).



  9. Ken says:


    Let us assume I have DA installed and running. I connect to my corporate network from my home network. While I am doing various tasks, I open IE and surf to a site that has questionable content due to a link redirection. On this nefarious website there is an IE exploit that compromises the OS of the machine and installs a trojan.

    Since the trojan is now at the OS level instead of the application level, is it not possible that this malware can create a bridge between the internet/home network and the corporate network? Even if the traffic needs to be either signed or encrypted, might this trojan be able to use DA for these functions?

    Do you agree that even though DA will prevent traffic from being routed from one interface to another, if malware was on the machine at the right layer in the stack, the PC could essentially become a bridge?



  10. alan says:


    I'm with Ken – I would like this question explored as I am re-implementing our remote access facility. I would like to use UAG/Win7/Direct Access but I am unsure how to deal with the scenario above – does Ken realise however that this scenario applies equally to a corporate PC within the corporate network? Why is a remote client PC any less secure?

    Is disabling split tunneling still not the most secure option? We have a fairly large corporate internet pipe

    and do not think that the additional traffic will be a problem, unless anyone knows otherwise.



  11. Patrick M says:

    Just to stir things up a bit,

    Do you allow machines conected to corpnet connect to the Internet at the same time?

    …in some way a bit like split tunneling without the tunnel. 🙂

    I agree that protection on corp-edge and the edge in this case (DA-client) can differ a little bit.


    -Patrick M

  12. Ken says:


    What's at issue is that when a machine is connected to two separate networks there is always the possibility it become a bridge if you compromise the machine at a low enough level (and with enough knowledge).

    Two refutations:

    Always up to date: Zero-day

    Compromised corp laptop brought in: NAC.


  13. MailMann says:

    Just a maybe stupid question, but why is split tunneling not supported with SSTP?

    My scenario is that I have huge problems getting Direct Access to work, due to a possible bug in SP1 with wildcard certificates from GoDaddy, and plan B was to use SSTP, so I had at least some external connectivity to offer my users. I managed it to work with the unsupported instructions from your college here: blogs.technet.com/…/uag-sstp-split-tunnel.aspx

    So my question is why is this not supported for SSTP?

  14. Steve Riley says:

    Hi, Tom!

    Split tunneling gives me no grief anymore.

    Whenever an organization allows even a single computer to operate outside the confines of its corpnet, that computer poses potential risk when it returns. Imagine that you've attached your computer to the hotel LAN at, say, a computer security conference. Most unprotected machines would probably get infected with something. Modern malware is much stealthier than viruses of old, and usually does its work by initiating outbound connections to some evil remote-controller and then awaiting instructions, often over well-known ports and protocols. Such attacks routinely bypass corporate firewalls. So regardless of whether your VPN permits or prohibits split tunneling, you've already lost the battle: as soon as that device connects to the VPN, it becomes a tool of the attacker. Mobile devices that come and go from the corpnet must be strongly, resiliently configured.

    There are also practical issues to consider when determining your VPN policy. My employer's user base can broadly be classified into two groups: those who use computers as tools for just getting work done, and hardcore developers/testers/geeks who are fully aware of risks and mitigations. Most users in the first group receive Windows machines that are domain joined, have user accounts that aren't admins, are locked down with group policy, are protected by anti-malware and a host firewall, and are kept up-to-date — IOW, built the way they should be, so that they are useless to attackers. A few prefer Macs, and they're also managed. Users in the second group typically run Linux, along with some Macs, as you might imagine, and are generally trusted to keep their machines secure.

    Less than half of our users work from a central office; the majority work from home or on customer sites. So split tunneling makes a lot of sense for us. We can still manage the machines remotely, and our users can connect to their home or their customers' networks and our network at the same time (often required for them to do their jobs). In the wider realm of worrying about which attack vectors really matter, split tunneling looks to be less of a problem than once thought.

  15. Povl H. Pedersen says:

    The DirectAccess devices are not managed before the company has spent significantly in upgrading to IPv6 on the core infrastructure. And then we have the question, how much of the network filtering and IDS/IPS is fully IPv6 ready ? Running IPv6 is a risk today.

    Malware on a PC working as a store and forward switch / router will work fine over DirectAccess.

    I see DirectAccess as a way to push IPv6, and not much more. Unless you have a need for IPv6 today, then wait, and maybe some other IPv6 VPN will be the dominant technology.

  16. Hazen Valliant-Saunders says:

    Good Day Tom;

    How does split tunneling reduce the "pivot" attack risk from a comprimised host? Let's say we have split tunneling enabled, and a host using this becomes comprimised from an IE zero-day exploit; the Command and Control traffic from this comprimised device is now traversing the internet and will have access to the tunnel and host contents will it not?

  17. Bob Hyatt says:

    hi there have followed the trail so far – my question is [hopefully] simple ….does DA require Split Tunnelling to work – i.e., if you can disable split tunnelling and DA still works is there any issue here (e.g., say performance etc)


Comments are closed.

Skip to main content