More on DirectAccess Split Tunneling and Force Tunneling

  • [アーティクル]

(Discuss UAG DirectAccess issues on the TechNet Forums over at https://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.

Disable Split Tunneling by using Force Tunneling

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

image

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 Problems with IP-HTTPS

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.

Split Tunneling Issues and Considerations

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:

  • Network security policy requires that all client traffic must go through the corporate web proxy and clients are never allowed to connect to the Internet directly.
    If this is the case, you need to make sure that users aren’t local administrators of their laptops, since a local administrator can disable the Force Tunneling configuration. In addition, you need to be aware that even when Force Tunneling is enabled, users are able to connect to resources before the DA connection is enabled. For example, DA client connections can’t be enabled if the client doesn’t have Internet access, and in some cases the client needs to connect to a portal to get that Internet access – so there is some degree of access available even before the DA client/server connection is established.
  • You think that disabling Force Split Tunneling will protect Internet bound traffic since it has to go over the DA connection to reach the Internet
    If this is the reason to disable split tunneling, then it’s not a good one, since the traffic sent to the Internet through one of your corporate proxies to the Internet it as susceptible to detection and interception as any other Internet communication once it leaves your proxy, .

Now let’s examine the relationship to VPN and split tunneling, since this is usually the basis for wanting to disable split tunneling:

  • With a VPN configuration, when split tunneling is disabled, users must connect to the Internet over the VPN link. But when the user disconnects from the VPN, that user is able to directly connect to Internet resources. This means that you are comfortable with having that user access the Internet without gateway inspection from time to time – and more likely most of the time, since users typically only connect to the corporate VPN when they need to.
  • If the previous is true, then your primary concern is that split tunneling is undesirable because there is some perceived security issue with having a user connected to both the Internet and the intranet (over DA) at the same time.

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.

  • The first issue that most VPN administrators are concerned about when it comes to split tunneling is the prospect of an Internet intruder somehow “routing” a connection from the Internet through the DA client into the intranet. The problem with this reasoning is that it would require bridging to be enabled on the DA client computer, which is not something enabled by default. This prevents any of the forwarding that the VPN admin might be concerned about. You can even use Group Policy to make sure that the user cannot enable connection bridging, assuming that the user even knows how to do this.
  • The second issue relates to malware that is run on the VPN client computer. Perhaps the malware is a network worm that can spread to the intranet, or some other type of malware that can gain access to information on the corpnet and bring it to the VPN client. Perhaps the malware could even enable bridging.
  • Regarding the second issue, turning off split tunneling does not solve this problem. When you allow clients to connect to the Internet, or to any non-filtered device (USB key, DVD, CD, etc) you have the same risk regardless of whether split tunneling is enabled or not.
  • Another thing when considering the second issue is that the software industry as a whole has become very good at dealing with situations where a network is unavailable for a period of time. The malware writers also know this and their code is just as effective in these scenarios. Malware can check-in on a periodic basis to see if there is something accessible on the corpnet, it doesn’t depend on an “always on” connection to be effective. So, the malware checks to see if the intranet is available, when it is, it grabs the information it’s looking for. Then after the VPN connection is dropped, the malware can connect to its “master” over the local connection to the Internet. Again, disabling split tunneling did nothing to prevent this problem.
  • Force Tunneling is a more complex solution, and can limit access to resources required by your users. Do the perceived benefits of disabling split tunneling really make up for the productivity losses due to lack of resource access?
  • Force Tunneling will be more expensive, since you’ll need to increase the bandwidth available to Internet connections, and scale up your proxy server deployment to handle the additional traffic. You also need to factor in the additional operational costs against the marginal (if any) benefits gained by disabling split tunneling
  • Enabling Force Tunneling could reduce Internet accessibility, because there are more components in the path between the client and server. Incremental losses of productivity per user could end up being significant when factored over the entire population of users.

Conclusion

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.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft ISDiX/SCDiX
UAG Direct Access/Anywhere Access Team
The “Edge Man” blog (DA all the time): https://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: https://twitter.com/tshinder
Facebook: https://www.facebook.com/tshinder

Bookmark and Share

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    August 11, 2010
    The comment has been removed
  • Anonymous
    June 20, 2014
    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.
  • Anonymous
    November 03, 2015
    Very informative discussion. Helpful