[This article originally appeared in "The Edge Man" blog at http://blogs.technet.com/tomshinder/archive/2010/03/02/why-split-tunneling-is-not-a-security-issue-with-directaccess.aspx]
(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.
I am more concerned about a remote machine that has picked up a keystroke logger calling home while connected to my corporate LAN than I am about some remote bounce attack via the client. With the traffic vectored through my corporate firewall, I have a shot at picking up the Trojan's activity at my firewall. If the client uses split tunnel, I never know that I have a compromised workstation. Ooops, was that my password database that just went out the split tunnel? Well at least the remote user's streaming audio radio station still works well. I guess that's more important. Bad choice, guys. No split tunnels is part of a layered security infrastructure; each piece brings a marginal increase in security. None on it's own ensures security.
Thats why you have polices that will prevent the client to connect if he doesnt have an AV on its local machine fully updateded and scaned, etc...
What if the malware is hiding in an SSL connection to what appears to be an innocuous location? Do you perform outbound SSL inspection, like what the TMG firewall does?