I’m happy to announce the release of the latest UAG DirectAccess Test Lab Guide – Test Lab Guide: Demonstrate Forefront UAG SP1 RC DirectAccess Force Tunneling, which you can download now at http://go.microsoft.com/fwlink/?LinkId=205454
I found this Test Guide to be especially interesting to put together. If you haven’t heard of Force Tunneling – here’s a little background.
By default, when you configure DirectAccess clients (both Windows DirectAccess and UAG DirectAccess), connections to the intranet are sent through the DirectAccess IPsec tunnels. Connections to Internet resources are sent directly to the Internet servers. This means there are two active paths: one path (the DirectAccess IPsec tunnels) carries traffic to and from the intranet, and a second path, for everything else (including Internet access). If this seems familiar to you, then you’re probably right – this configuration is sometimes referred to as “split tunneling”.
Now, split tunneling has a bit of a history behind it and like all issues that have a history, there are many people who might carry the historical baggage with them. Split tunneling had been considered in the past to be a potential security issue for remote access VPN client connections, and that’s where the idea of split tunneling got it’s checkered reputation. Because of this, many firms will not allow split tunneling. However, this attitude is slowly changing, as we’ve found that about half of enterprises now allow split tunneling for their remote access VPN client connections.
For more information on split tunneling issues, check out my articles:
Why Split Tunneling is not a Security Issue with DirectAccess
More on DirectAccess Split Tunneling and Force Tunneling
Although we don’t consider split tunneling to introduce security issues when compared to non-split tunneling configurations, many organizations still do. For that reason, we’ve made it possible to disable split tunneling for DirectAccess clients, using a configuration that we refer to as “Force Tunneling”. When Force Tunneling is enabled, all traffic is sent over the DirectAccess IPsec tunnels, so that both intranet bound and Internet bound traffic is sent over the DirectAccess tunnels. While this will exact a performance toll on the DirectAccess server, it does enable you to force all traffic over the DirectAccess connections.
So what happens to the Internet bound traffic after it goes over the DirectAccess tunnels? UAG SP1 provides you two options:
- DirectAccess clients can be configured to use a web proxy (which limits them to HTTP and HTTPS when connecting to the Internet)
- DirectAccess clients can be configured to “bounce” Internet connections off the UAG DirectAccess server by taking advantage of the UAG NAT64/DNS64 service. This option enables the DirectAccess clients to use any protocol to connect to the Internet
In the Test Lab Guide I go over both of these configuration options. When testing access through a web proxy, you’ll be using TMG 2010 as the web proxy provider.
I hope you like this Test Lab Guide! Let me know if there’s anything that you think I should add to it, or if there are some other configuration options you’d like to have included to make it more comprehensive. If you have problems with this Test Lab Guide, or any other Test Lab Guide, let me know! Just write to the email address in my sig line and I’ll get right back to you.
Knowledge Engineer, Microsoft DAIP iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: https://twitter.com/tshinder