There are three places where certificates are involved in a DirectAccess configuration:

1.  SSL certificate for the NLS website

A major part of the way that DirectAccess works is your Network Location Server (NLS) website. This is simply a website running inside your corporate network that the DA client machines are going to query. Basically, if they can see it they determine they are inside the corporate network, and if they cannot see it they determine they are outside of the corporate network. The NLS website is a very simple requirement, the only special instruction on creating the site is that is must be HTTPS with a valid SSL certificate so that it cannot be spoofed. This certificate gets installed onto whatever web server you are using in-house to host the NLS website. The only machines that are going to be accessing this website are your corporate DA computers, therefore the SSL certificate does not need to be one that was purchased from a public CA (though it can be if you choose), an SSL certificate generated from your internal CA server will work just as well, since all of your domain-joined corporate machines should already be configured to trust this CA.

2.  SSL certificate for the IP-HTTPS listener

6to4 and Teredo connect without utilizing SSL, so many of your client connections are not relying on this certificate. However, when a DA client fails to connect using 6to4 or Teredo, they will fall back and try to connect using IP-HTTPS. IP-HTTPS traffic is required to be authenticated as SSL traffic, and therefore requires a valid certificate installed onto the UAG/DirectAccess server. For this certificate I absolutely recommend going out and purchasing one from your public CA of choice. Doing so allows them to retain responsibility for publishing the CRL and managing that certificate for your external users. It is technically possible to use an SSL certificate from your internal CA server and publish the CRL publically, but I have seen so many people on the forums attempt and fail at doing this that I wouldn’t even bother trying. Once this certificate is installed into the store on the UAG/DA server, you choose for UAG to utilize the certificate from the “IP-HTTPS Certificate” screen inside Step 2 of the DirectAccess configuration wizards.

3.  Machine certificates for the IPsec tunnels

This is the part that most admins are not familiar with. You must have a CA server running inside your corporate network, which will be used to issue machine certificates to all of the DirectAccess client computers, as well as all of your DirectAccess gateway servers. When you install the CA server role onto a Windows server, it installs some default certificate templates. One of those templates is called the “Computer Template”, and this is the one that I recommend using to issue your DirectAccess certificates from. You don’t need to modify anything with this template, simply issue certificates to all of the machines involved based off this template and you’re in business. You can issue certificates manually if you so choose, by requesting them from inside the certificates MMC snap-in (make sure to snap-in the “Computer account” templates instead of User), or you can automate the issuance of your certificates by setting up AutoEnrollment inside Active Directory. Once your certificates are in place on the server and the clients, you configure this part on the next screen inside Step 2 of the UAG DirectAccess configuration wizards, “IPsec Certificate Authentication”. Simply choose the CA server that you use to issue these certificates.

If there is a reason that you do not want to utilize the default Computer template, you can create a custom template and use it to issue certificates as well. There are four main requirements that you need to incorporate into your custom template:

1. It must serve the intended purpose of Client Authentication
2. It must serve the intended purpose of Server Authentication
3. The Subject name of the certificate must be the CN of the machine (FQDN of the computer its being assigned to)
4. The SAN (Subject Alternative Name) of the certificate must be the DNS Name of the machine (also the FQDN of the computer its being assigned to)

That’s it! Three places where certificates are required for DirectAccess. I hope this guide is helpful for your implementation, and as always if you have any questions or comments, please feel free to reach out to me directly.

Jordan Krause
IVO Networks
jordan.krause@ivonetworks.com

Let’s start with the client side of the connection. When a DirectAccess client computer connects to its DirectAccess gateway in the corporate network, it chooses one of three transition technologies to establish a tunnel. A transition tunnel is needed because DirectAccess packets are IPv6 packets, but most of the internet today is still IPv4. So each of the three client-side transition technologies – 6to4 | Teredo | IP-HTTPS – each work to accomplish the same goal: Encapsulate the IPv6 packets inside IPv4 headers so they can be transmitted over the internet.

6to4
The DirectAccess client computer attempts to establish a 6to4 tunnel first, but can only do so if the client’s NIC has been assigned an actual public IPv4 internet address. This is not a very common scenario, the most common situation where you might find yourself with a public IP address is when using a broadband card provided by a cellular carrier. I have seen some hotels issue public IPs to computers inside their network as well, though this is rare and I expect it will become increasingly rarer in the future. 6to4 uses IP Protocol 41 as its transport method, and occasionally cell carriers will block Protocol 41 on their networks which means 6to4 cannot function anyway. This potential problem that would result in a helpdesk call combined with the rareness of 6to4 being used in the first place leads me to recommend as a best practice disabling the 6to4 interface on all of the DA client computers via GPO. One other point to add to this is that if/when you move to a multi-site DirectAccess deployment (multiple DA gateways in different locations) you must disable 6to4 anyway.

Teredo
Teredo is the most common connectivity method for DirectAccess clients. It attempts to connect whenever a DA computer is sitting behind a NAT. For example, when you are sitting at home and you have received a “192.168.something” address from your home router. One recommendation I always make during installations is to use a GPO (same GPO as the one that disables 6to4 perhaps) to set your Teredo State to “EnterpriseClient” on the client machines. By default Teredo runs in “Client” state and will not connect if the computer is sitting inside of a domain network. Sometimes users plug into clients or other business networks, or sometimes users have domains on their home networks, and setting Teredo to EnterpriseClient allows Teredo to connect when inside a domain network. Teredo does the same job as 6to4, encapsulates IPv6 packets inside IPv4 headers, but Teredo uses UDP port 3544 for its transport. Therefore, if you are sitting behind a port restricting firewall that doesn’t allow UDP…

IP-HTTPS
This is the method of last resort for creating a transition tunnel for DirectAccess. IP-HTTPS takes the IPv6 packet, encapsulates it inside an IPv4 header, and then throws that inside an HTTP header that is encrypted, creating an SSL traffic stream. This enables DirectAccess traffic to make its way successfully through port restricted firewalls (even a firewall where only HTTPS traffic is allowed), but is the method of last resort because you are essentially encrypting every packet twice, once with the standard DirectAccess IPsec encryption and then again with the SSL encryption. So this is a less efficient protocol, which is really the only reason that it is not the one and only protocol.

ISATAP
The Intra-Site Automatic Tunnel Addressing Protocol is also an IPv6 transition technology, similar to the three mentioned above. Its job is also to encap IPv6 packets inside IPv4 headers, but the main difference is that ISATAP is for use INSIDE your corporate network. UAG contains a great feature – NAT64/DNS64 – that converts the IPv6 packet stream into IPv4 for application servers and networks that do not understand IPv6 (more on that later) but occasionally you may have the need to make an outbound initiation from the internal network out to a DirectAccess connected client machine. The most common example of this is a Helpdesk PC trying to RDP into a DirectAccess laptop. When you want to generate a true outbound initiation like this, when the Helpdesk personnel punches “CLIENT1” into the RDP client, their PC is going to ask DNS how to get to CLIENT1. DNS is going to respond with the IPv6 address that the DA computer is currently connected with, and then that Helpdesk computer has to have an IPv6 layer of connectivity to be able to establish that connection. If you have native IPv6 inside your network then great, you don’t need ISATAP. If you do not have native IPv6 inside as most companies do not, you can use ISATAP to create a “virtual IPv6 cloud” inside your network. Your UAG box will act as an ISATAP relay which you can think of as an IPv6 DHCP server. You configure your Helpdesk PC to point at the UAG server for its ISATAP configuration, and it gets assigned an ISATAP IPv6 address. Then when the RDP connection takes place, those packets stream over the ISATAP connection (which is taking the IPv6 packets and putting them in IPv4 headers so your internal network and routers don’t need to know anything about IPv6) and those packets can then make their way successfully outbound to the DirectAccess client machine.

Note: Neither native IPv6 or ISATAP are required for a successful UAG DirectAccess implementation. Many management functions like Group Policy updates and patches for the DA client computers are actually “pulls” not “pushes” and therefore the management servers inside the network don’t actually need outbound access to these client computers as they are simply responding to the “pull” request that was initiated by the client. Those pull responses will happen successfully without any form of IPv6 connectivity inside the office.

NAT64 / DNS64
These two technologies (pronounced “NAT 6 to 4” and “DNS 6 to 4”) are included with UAG and are the mechanisms used to make your IPv6 DirectAccess packets be able to successfully contact IPv4 application servers inside your network. When your Outlook requests “EXCHANGE01” the DA client will ask your UAG appliance how to contact EXCHANGE01. UAG in turn asks DNS. If DNS responds with a AAAA (IPv6) record, UAG passes that along to the client who is happy to simply use the IPv6 record for communications back and forth. However, if EXCHANGE01 is a Server 2003 that doesn’t know anything about IPv6, DNS is going to return a regular A record which the DirectAccess client computer doesn’t know what to do with. Therefore, when DNS64 in UAG realizes that it’s talking to an IPv4 host inside the network, it creates a “fake” IPv6 address on the fly and returns that address to the DA client instead. Then DNS64 and NAT64 combine to create a transport method between client and server, where the client always thinks it’s talking to an IPv6 server, and the server always thinks it’s talking to an IPv4 client. There is nothing to configure to make this work, it simply does. It’s a beautiful thing!

IPsec
One thing I didn’t discuss is the actual encryption of the DirectAccess traffic. Of course an IP-HTTPS stream would be SSL encrypted, but you obviously wouldn’t want clear-text packets flowing through the internet inside a UDP tunnel when connected over Teredo! Therefore regardless of what transport method the client chooses to connect with (6to4, Teredo or IP-HTTPS) inside that transition tunnel are IPsec tunnels which are carrying the actual packets the client is sending and receiving. In a typical DirectAccess implementation there are two IPsec tunnels at work on every DirectAccess client. The first is called the “Infrastructure Tunnel” and is a tunnel that is automatically established based on computer account and certificate authentication. This first tunnel is restricted only to your management servers. Domain controllers so that the user can successfully authenticate and so that Group Policies can be pulled down, and then whatever other management servers inside your network that you might want to have access to the DirectAccess client computers prior to user authentication. Then once user authentication does happen, a second IPsec tunnel is established based on both computer certificate and user authentication and this second “Intranet Tunnel” carries all of the user driven traffic.

There are potentially many more acronyms that we could discuss here. Things like NLB, NAP, OTP, etc etc. Those items are a little bit more generic and though they do have specific tie-ins with DirectAccess, I think I’ll leave it at that for today. As always, please feel free to reach out to me directly if you have any questions.

Jordan Krause
IVO Networks
jordan.krause@ivonetworks.com

http://blogs.msdn.com/b/mvpawardprogram/archive/2012/02/13/five-reasons-you-should-consider-directaccess.aspx

Jordan Krause
IVO Networks
jordan.krause@ivonetworks.com

So why not create automatic, offsite backups for yourself? FOR FREE

I’m a Microsoft DirectAccess enthusiast, and as such I am always trying to keep my eyes open for new ways in which it can be used to make life easier on IT. This is absolutely one of those areas. If you have DirectAccess, you already have the infrastructure needed to establish a remote backup site – at any physical location of your choosing. All you have to do is:

1. Build out your backup machine – This can be a desktop, laptop or server and it can be running Windows 7 or Server 2008 R2 (yes, Server 2008 R2 can also be a DirectAccess client).

2. Enable DirectAccess on this machine – Add this new machine to your Security Group or OU for DirectAccess so that it receives the DA connectivity settings and the necessary certificate from your CA server.

3. Move the machine to a remote location of your choosing.

That’s it! As long as the machine gets internet connectivity at the remote location it will establish itself some DirectAccess IPsec tunnels, and you will have a 24×7x365 connection to your new offsite backup server. You can now use whatever backup methods you choose, and push the results at this offsite machine just as if it were another machine sitting inside your corporate network.

Keep in mind that as with any DirectAccess client, you will need to create Firewall rules that allow the necessary ports for whatever backup method you are using. I recommend doing this with a GPO. Create a new one, add the inbound firewall rule or rules to it, and assign it to this client machine. For example, if you are using a backup utility that simply needs access to be able to push files at a file share that is running on the offsite backup server, open up TCP 445 inbound and you should be all set.

This method for offsite backups could prove especially helpful for businesses that do not have a second location or if they do it may not have an expensive WAN link keeping the two connected. This offsite backup server could be placed anywhere, at an employee’s home for example. You will have complete management access of this backup server at all times because it is connected via DirectAccess. You can push patches and GPO settings at it, remotely control it, whatever you might need to do to ensure safety and security of your data.

Jordan Krause
IVO Networks
jordan.krause@ivonetworks.com

Some of these laptops were getting this IPv6 address from a home router, and some were getting an IPv6 address assigned to them by a new 4G card that the user had recently acquired. The clients were also getting an IPv6 address for Teredo or IP-HTTPS, but the problem showed up near the bottom of the DirectAccess Connectivity Assistant logs:

The DirectAccess IPsec tunnels (at least some of them) were attempting to establish themselves using the native IPv6 address instead of the Teredo/IP-HTTPS addresses. The resolution to the problem on all machines was to disable that native IPv6 address from being assigned to the laptops. Since we didn’t want to try walking the users through reconfiguring their home routers we unchecked TCP/IPv6 from the NIC properties and that took care of it for the home users:

And for the 4G card users we found a setting in the software for the 4G card – it was basically just a checkbox for “IPv6” that the user was able to uncheck and the next time they connected with the 4G card, it issued only an IPv4 address, not an IPv6 address and then the tunnels established correctly over Teredo/IP-HTTPS.

The official word from Microsoft is that client-side IPv6 is supported, but after reviewing the details of these cases they agreed that the best solution to this issue is to simply stop those native IPv6 addresses from being assigned to the client machines.

Jordan Krause
IVO Networks
jordan.krause@ivonetworks.com

-          Lync web services publishing

-          Dynamics CRM 2011 publishing

-          SharePoint 2010 with Office Web Apps

-          Improved browser support

Full details are available here – http://technet.microsoft.com/en-us/library/hh490321.aspx

Additionally, UAG SP1 Update 1 includes the recently released MS11-079 security update.

Download Update 1 here – http://www.ivonetworks.com/downloads/uag_sp1_update1.zip

If you are running UAG before SP1, you cannot make use of this new update and therefore should install the standalone hotfix for MS11-079 which corresponds to your current UAG level. Visit the link below for a list of downloads available:

http://technet.microsoft.com/en-us/security/bulletin/ms11-079

As always, please contact your IVO support engineer should you have any questions at all. Thanks!

Jordan Krause
IVO Networks
jordan.krause@ivonetworks.com

The traveling user connecting to a home datacenter:

Sometimes users travel, and you want them always connected back to their primary datacenter to reach their information. For example, you may have a US employee traveling to India, but their primary email and file servers are located in the US, and so when they are in India you would want DirectAccess to connect them back to their US datacenter. This is what happens by default, and there is nothing special whatsoever you would need to establish to make DirectAccess function like this. But maybe you also have a datacenter in India that is the primary location for email and files provided to India based employees. So your requirements are basically the same – you want US employees to connect to the US datacenter no matter where they are in the world, but you want India employees to connect to the India datacenter no matter where they are in the world. This “manual distribution of DirectAccess clients” is possible with UAG DirectAccess today. You can place a DirectAccess entry point in the US, and another DA entry point in India, and by utilizing separate GPOs for the client connectivity settings, you can create this scenario very easily by simply adding the US computer accounts to the “DA_Clients_US” group, and adding the India computer accounts to the “DA_Clients_India” group. If you ever had a need to move a laptop from one entry point to another, you simply move the computer account from one group to the other, and the next time that laptop receives its Group Policy refresh, it is automatically reconfigured to connect through the new entry point.

The traveling user connecting to geographically local datacenters:

What if you have traveling users that you would rather have connected through the datacenter in the local geographic region they are located? Unfortunately this is not a scenario that DirectAccess is (yet) capable of providing on its own, but with UAG in the mix it makes for a pretty easy solution to this requirement. Simply create a UAG portal in each of your datacenters that allows employees to login and have a VPN session created. So when that US user travels to India, they can launch a simple web address from their browser, login, and then have full network connectivity to the India datacenter. If for some reason they forget to establish this connection, their DirectAccess will still be connecting them automatically to the US datacenter where they can work like normal, as if they are still in the US office.

To summarize, I believe the need for scenario #2 where users have to connect to their geographically local datacenter is dwindling. With internet speeds being what they are today, even reaching “across the pond” is not a big deal. I would personally like my users continuing to connect through their usual point of entry and always having access to the same resources that they do from anywhere else, this is certain to reduce helpdesk calls. But, if ever there is some specific reason that users would be expected to connect to a datacenter other than their home, it is easily accomplished with UAG.

Jordan Krause
IVO Networks
Jordan.Krause@ivonetworks.com

Top of log file
At the very top you’ll see a quick summary of whether or not the DCA “thinks” it can see inside the corporate network successfully. It’s important to note that this overall status is not always accurate. For instance, if you have configured the DCA to probe more than one internal resource, it might be able to see one and not the other, and even though the DirectAccess tunnels are established correctly, it may still report “Corporate connectivity is not working correctly” – which is actually untrue.

Ipconfig /all
Pretty self-explanatory here. This shows all IP addresses on the client computer. You should have a local LAN IP address as well as at least one IPv6 address assigned from the Transition Technologies (6to4, Teredo or IP-HTTPS).

Netsh int teredo show state
This shows the particulars of Teredo. You want “Type” to be either “client” or “enterpriseclient” and when Teredo is successfully connected, it will show a “State” of “qualified”. If Teredo cannot connect, it is likely because of a port restricted firewall blocking UDP on the user’s internet connection, and Teredo will report “Primary server unreachable over UDP”. However, this should not cause too much concern, because if Teredo is unable to connect, IP-HTTPS should automatically connect and establish the DA tunnels that way.

Netsh int httpstunnel show interfaces
This shows the details of the IP-HTTPS connection. If 6to4 or Teredo has made a successful connection, IP-HTTPS will show as “Disabled”. If you do not have 6to4 or Teredo connectivity, IP-HTTPS will show either “Active” or it will display an error code that will be useful for tracking down anything potentially wrong with the IP-HTTPS connection. Problems with IP-HTTPS are typically certificate related.

Netsh dns show state
These are the 3 important pieces here that you want to ensure are set correctly:
Network Location Behavior : Let Network ID determine when Direct Access settings are to be used
Machine Location : Outside corporate network
Direct Access Settings : Configured and Enabled

Netsh name show policy
This should reflect the information you provided during the DirectAccess configuration wizards on the “DNS Suffixes” screen. This lists the NRPT (Name Resolution Policy Table) which determines what names go through the DA tunnels, and what names do not. If you do not have any information listed here, your machine has probably not received the settings from the DA Client GPO yet, and you should bring the laptop back into the corporate network for a “gpupdate /force”.

Netsh name show effective
When outside the corporate network, this should show the same information as “netsh name show policy” above. If it does not, then you likely have a problem of the client machine not correctly realizing that it is outside of the corporate network, or the NRPT being forced to turn off for some reason (double check the settings in “netsh dns show state” to ensure they are set correctly as indicated above).

Netsh adv mon show mmsa
This is a listing of your Security Associations, which are basically your IPsec tunnels. You should have tunnels here that have a second authentication of “UserNTLM” which indicates the “Infrastructure Tunnel”, as well as tunnels with a second authentication of “UserKerb” indicating the “Intranet Tunnel”. If you do not have any tunnels listed here, DA is not working. You could have a problem with the Transition Technologies not establishing (6to4, Teredo, IP-HTTPS), or you could have a problem with your computer certificate that is assigned to your computer not authenticating properly.

Netsh nap client show state
This lists information on the status of Network Access Protection on the client. If you are not using NAP certificates with your DA environment, this section can be ignored.

Wevtutil query –event Microsoft-Windows-NetworkAccessProtection…
Another section dedicated to NAP that can be ignored if NAP is not enforced.

Netsh int ipv6 show int level=verbose
Some statistics on your IPv6 interfaces, I have never found a case where the data here was necessary for any troubleshooting.

Netsh advf show currentprofile
This shows which Windows Firewall profile your current internet connection has been assigned. You want to ensure that you have either “Public” or “Private” Profile Settings because the DirectAccess Connection Security Rules are only activated while connected to network in which Windows Firewall has been set to use the Public or Private profile settings. You also want to ensure that the Firewall “State” is ON. If set to OFF, you need to figure out what is disabling your Windows Firewall and change it, because WFAS is necessary for a successful DirectAccess connection.

Netsh advfirewall monitor show consec
Some additional information about your firewall settings here, as well as another listing of the Security Associations (IPsec tunnels). The useful information here is really whether or not you can see your IPsec tunnels established, but that information is already available elsewhere in the logs.

Certutil –store my
This command lists the certificates that are installed on your client computer. For a successful DirectAccess connection, you must have a “Machine” certificate issued by your internal CA server that is valid.

Systeminfo
Some general information about the client computer where you are running DirectAccess. Typically I only check the “OS Name” – you want to make sure the client is running either Windows 7 Enterprise, Windows 7 Ultimate, or Server 2008 R2, because those are the only Operating Systems that can be DirectAccess client computers.

Whoami /groups
Listing of the local computer groups that you are part of.

If there is anything you would like added to this list or detailed our further, please let me know and I will update accordingly. Thanks!

Jordan Krause
IVO Networks
Jordan.Krause@ivonetworks.com

DNS Effective Name Resolution Policy Table Settings
Note: DirectAccess settings would be turned off when computer is inside corporate network

Must be a problem with NLS right? Maybe you forgot to exclude it from the NRPT? Maybe not – remember, this is an environment where DA works just fine on other computers. So let’s take another look at the log file. We’ll make sure the client machine is recognizing correctly that it is outside of the corporate network. Netsh dns show state:

Name Resolution Policy Table Options
Query Failure Behavior : Always fall back to LLMNR and NetBIOS if the name does not exist in DNS or if the DNS servers are unreachable when on a private network
Query Resolution Behavior : Resolve only IPv6 addresses for names
Network Location Behavior : Never use Direct Access settings
Machine Location : Outside corporate network
Direct Access Settings : Configured and Disabled
DNSSEC Settings : Not Configured

Hmm, so it is correctly identifying that it is externally connected. But take a closer look at the output of that command:

Name Resolution Policy Table Options
Query Failure Behavior : Always fall back to LLMNR and NetBIOS if the name does not exist in DNS or if the DNS servers are unreachable when on a private network
Query Resolution Behavior : Resolve only IPv6 addresses for names
Network Location Behavior : Never use Direct Access settings
Machine Location : Outside corporate network
Direct Access Settings : Configured and Disabled
DNSSEC Settings : Not Configured

“Never use Direct Access settings” – that sounds wrong, doesn’t it? Sure enough. This is a simple registry key to change from “Never use” to “Automatic” where it should be set. So far a cause for this registry key being incorrectly set has not been brought to my attention, but at least it’s a simple fix. Head over to this registry key on the client machine and change it from “2” to “0” (zero):

HKLM\Software\Policies\Microsoft\Windows NT\DNSClient
EnableDAForAllNetworks=0

Jordan Krause
IVO Networks
Jordan.Krause@ivonetworks.com

Unfortunately, the phrase “Split Tunneling” has caused many a VPN administrator to cringe over the past 20 years. Many of the reasons why that mentality exists are the fault of those original VPN technologies from decades ago, and have been resolved for quite some time. Here are a couple of the points that I regularly hear:

1. Bridging the connection. Say you are sitting in your favorite coffee shop, enjoying their free WiFi and justifying your longer-than-allotted lunch break by flipping open the lid of your laptop. Apparently there is this idea out there that, once you connect to the corporate network via VPN, somehow any yahoo also sitting in that coffee shop is going to be able to bridge the connection and gain access to your network. Now, there may or may not be a way to configure your work computer to be able to accomplish this, but it would certainly require administrative rights and a good amount of technical knowledge to be able to setup. So in a VPN world, if you are concerned that your users may be maliciously attempting to create a network bridge for other users to drive across, disable their ability to do so by restricting their rights (they should be anyway) or killing their access to any bridging tools they might potentially use to accomplish this. By the way, this section of the conversation is not really anything to do with DirectAccess, but rather regular VPN connections. When talking about DirectAccess (which is what this article is really about) you needn’t be concerned anyway, because all of the traffic coming across the IPsec tunnels is going to be authenticated as having come from the source computer of the DirectAccess client, and thus traffic initiated from a different computer is not going to make its way across the tunnels.
2. Malware. If you allow DirectAccess split tunneling, you are basically sending all corporate traffic to the corporate network, and sending all “other” internet traffic directly to the internet. What if the user hits a malicious link on a social media site and gets infected? My response to this – How is this any different than any VPN? Malware doesn’t care whether or not it’s connected to a corporate network “right now”. It’s more than happy to hang out and wait until you establish that VPN connection! So even if you force tunnel VPN currently, unless you disable the user’s ability to access the internet AT ALL while disconnected from the VPN, this is not a valid concern. In this case, DirectAccess is actually much better than VPN because with DA, as soon as the internet connection is established, so are your tunnels, and thus if you are using DA Force Tunneling, all of your internet traffic flows through the datacenter (and your web filtering devices) all the time. The user cannot turn it off.

So when deciding on a configuration path for DirectAccess, Split Tunnel or Force Tunnel? This article is intended to alleviate any fears (sorry thrillseekers) surrounding Split Tunneling, because they just aren’t valid. However, in some instances Force Tunneling may still be the way to go. If you have a written security policy, for example, stating that all internet traffic from remote machines has to flow through the corporate datacenter all the time, there you go – DirectAccess in Force Tunnel mode will fit the bill. If your company has such a policy, give me a shout. I would love to hear what current technology is being used that can actually accomplish that.

There are also some downsides to using DirectAccess Force Tunneling. Primarily, it is slower. This really is twofold. First, Force Tunneling DirectAccess means that you are restricting your connections to only use the IP-HTTPS connectivity platform, which is less efficient than 6to4 or Teredo that could potentially be used in Split Tunneling. So the user’s experience will be slightly slower. Also, you will be pumping all internet traffic from these machines through the datacenter all the time, so your bandwidth utilization is going to increase, and that means increased costs.

I’ll leave it at that for now, if you have any questions or concerns (I’m always open to being corrected by somebody smarter than I), as always please feel free to contact me.

Jordan Krause
IVO Networks
Jordan.Krause@IVOnetworks.com