(Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag)
When you configure a Windows DA server or UAG DA server-based DirectAccess (DA) solution, the default setting is to enable split tunneling. What split tunneling refers to is the fact that only connections to the corpnet are sent over the DA IPsec tunnels. If the user wants to connect to resources on the Internet, the connection is made over the local link (that is to say, the connection is sent directly to the Internet based on the IP addressing configuration on the DA client computer’s NIC).
The advantage of split tunneling is that users have a much better computing experience, especially when accessing Internet based resources. In addition, users on the corpnet are likely to have a better computing experience when accessing resources on the Internet, since the DA client traffic isn’t consuming corporate Internet bandwidth to connect to Internet resources. The combined advantages of improved DA client and corpnet client Internet computing experience makes it worthwhile to make split tunneling the default configuration for DA client/server communications.
However, you might not want to enable split tunneling. If that is the case, then all traffic from the DA client to any resource must go over the DA IPsec tunnels. Traffic destined for the intranet goes over the DA IPsec tunnels, and traffic destined to the Internet also goes over the DA IPsec tunnels. Split tunneling is disabled when you enable Force Tunneling for the DA client connections. Force Tunneling is enabled via Group Policy:
Computer Configuration\Administrative Templates\Network\Network Connections\Route all traffic through the internal network
When Force Tunneling is enabled, all traffic is sent over the DA client tunnel using the IP-HTTPS protocol. IP-HTTPS is one of the three IPv6 transition protocols that the DA client can use to connect to the DA server. The other two protocols are 6to4 (used when the DA client is assigned a public IP address) and Teredo (used when the DA client is assigned a private IP address and has outbound access to UDP port 3544 to the DA server). IP-HTTPS is used when the DA client is assigned a private address and outbound access to UDP port 3544 to the DA server is not available.
The problem with IP-HTTPS is that it should be considered, and is instantiated as, a protocol of last resort. There are a number of reasons for this, with the primary reason being that it’s the lowest performing of the IPv6 transition technology protocols. Think about it – the client and server have to negotiate and use IPsec encryption and then also has to negotiate and encrypt the HTTPS (SSL) session. This “double encryption” takes a toll on the processor. In addition, IP-HTTPS has a much higher protocol overhead, so that the area available for the payload for each packet is smaller, requiring more packets to be sent to communicate the same amount of data, thus impairing performance even more.
In addition to the performance issues are the Internet access issues for the IP-HTTPS client. Remember that all communications from the DA client to the DA server are over IPv6. The DA client never uses IPv4 to connect to resources through the DA client/server channel. Because of this, you will need to deploy an IPv6 aware web and winsock proxy server on the network that the DA clients can use to connect to the Internet, or use the UAG DirectAccess solution, which includes an IPv6/IPv4 protocol translator that allows the DA client to connect to Internet resources through a IPv4 web and winsock proxy server, such as the ISA or TMG firewall. This adds more complexity to an already problematic situation.
And there is one more “gotcha” when you use Force tunneling. As I’ve said, all communications between the DA client and server are over IPv6. What this means in practice is that the client application must be IPv6 aware. This is not to say that the server side of the application needs to be IPv6 aware and in most cases the server side will work fine with the help of the UAG NAT64/DNS64 IPv6 protocol translator if the server side is only IPv4 aware – but the client side must always be IPv6 capable.
Thus, Force Tunneling can be a problem in those scenarios where the client side is not IPv6 aware. For example, the Office Communications Server Client (at the time of this writing) is not IPv6 aware. In order for the DA client to reach the OCS server, it will need to use the direct connection to the Internet to connect to the OCS server located on the corpnet. If you try to force the OCS client/server communications over the DA connection, the attempt will fail because the OCS client is not IPv6 aware. Any other non-IPv6 aware client application will fail, as it won’t be able to connect over the Internet because split tunneling is disabled.
At this point it’s worthwhile to think about split tunneling and the reasons why you wouldn’t want to enable split tunneling to determine if those reasons are actually applicable in a DA client/server solution. It might turn out that the assumptions you made when deciding against split tunneling weren’t as valid as you thought, and that the perceived risks of split tunneling were overstated to the extent that split tunneling may no longer be an issue.
Most network admins developed their opinions regarding split tunneling based on their understanding of how VPN clients work, and in many (most?) cases these opinions were derived from issues that were extant in the early to mid 1990s and with non-Microsoft VPN clients.
What are some of the reasons why you think you need to disable split tunneling? Two of them might include:
Now let’s examine the relationship to VPN and split tunneling, since this is usually the basis for wanting to disable split tunneling:
So the question at this point should be “what are the problems with allowing users to connect to the Internet and the intranet at the same time?” – as this appears to the crux of the split tunneling issue.
From this assessment, it seems clear that there is only one valid scenario where you would want to disable split tunneling and that’s when you want to force all traffic through the corporate web and/or winsock proxy server so that the traffic is filtered to reduce the risk that malware can be downloaded to the DA client over the Internet. I admit, that if there is a weak link in the DA story, that this is it.
However, this weak link isn’t a DA issue because the fact is that there are no longer any “bolted down” corpnet clients. Most organizations have moved to laptops for their employees, and those mobile devices travel between the Internet filtered corpnet and the non-filtered Internet on whatever external network those clients are connected to. Therefore, unless you’re using a 3rd party solution that enforces Internet access policy to computers that aren’t connected to the corpnet, there is little to be gained by forcing the DA clients over the corporate web filters. Of course, the ideal situation would be to use an Internet based web filtering solution so that the DA clients have corporate web access policy forced on them as well.
Another thing that should be clear at this point is that the issue of “routing” communications from an Internet based host to the corpnet doesn’t happen on Windows clients of today. So that concern, perhaps inherited from the 1990s, is no longer an issue and doesn’t represent a security issue for VPN or DirectAccess clients. Whether the client is connected intermittently (as with VPN clients) or is “always on” (as with DA clients) really doesn’t make a difference in terms of the overall security posture provided by the DA client.
In sum, I highly recommend that you do not disable split tunneling for your DirectAccess clients. The benefits from doing so are virtually none, but the cost, complexity and productivity hits imposed by enabling Force Tunneling can be substantial.
Tom Shinder email@example.com Microsoft ISDiX/SCDiX UAG Direct Access/Anywhere Access Team The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
On the proxy issue I thought I'd share the following:
We are running a DA trial using UAG (so we don't need an ipv6 proxy). Our clients are configured to do auto-discovery for a proxy so use wpad.domain.local in DNS. When a laptop client is working remotely we find that the laptop still does the correct WPAD lookup to internal and the browser then configures itself to use the internal proxy.
This means that we still have split-tunnelling enabled but have a scenario where users are connecting to the corporate proxy when they are just browsing the web.
I think this is probably the "best of both worlds" scenario :)
I really love DA with UAG but think that the UAG component is essential to realistically deploy DA for most networks, it just makes everything work!
Very good and confirms what I expected to happen. I agree that the best of both worlds is best from a security perspective. You're right about UAG being a requirement to really use DA in a production environment, since it gives you the IPv6/IPv4 translations technologies and HA solutions (array/NLB).
You haven't really discussed the main problem with split tunneling and that is that a client machine can exist on two networks simultaneously. Split tunneling can create a situation where your internal network is bridged onto the internet.
As a simple example an intruder could remote connect to the client over the internet, then browse your internal network. Think of the potential with a BO2K (or modern equivilant) on one of your direct access machines. Hop on to the client via internet IPV4, then trawl the internal IPV6 network at your leisure.
The reason why some admins want all traffic to go via the proxy is to help prevent nasty software and malware call backs, as much as the potential legal liability from downloading copyrighted or obsense materials.
This should be a real concern for an organisation of any size!
On another note, thanks for the info on the forced tunnel - I'll give that a try.
To overcome the captive portal issue, we use ConnectSolve which enables us to handle the captive portal on our iPhone or Android phone and then allow our laptops through.