It has been a busy August for us in the IT Department at Catapult. We have been heads down with a breakthrough network technology from Microsoft called DirectAccess. This blog post describes what we encountered and some considerations for enterprise deployments.

What is DirectAccess?

The vision of DirectAccess is to keep clients continuously connected to the intranet. DirectAccess is a feature within Windows Server 2008 R2 that allows Windows 7 Enterprise and Ultimate to get always-on, bidirectional connectivity from locations inside or outside the corporate network through IPSec and IPv6. It is just as secure as traditional VPNs because it uses IPSEC for Encryption and supports multi-factor authentication.

DirectAccess Benefits

DirectAccess has many benefits for IT Organizations, including the ability to “manage out” remote systems.

  • Clients computers can now process Group Policy wherever they are. Think about what this means for easing software deployment and inventory.
  • Reduces IT Support costs – keeps VPN client software out of the image. Many VPN clients have issues with 64-but guest operating systems. If you’re facing a decision on whether to upgrade or replace your VPN solution because it does not support 64-but guests, then consider DirectAccess.
  • Desktop Management software like System Center Configuration Manager can configure/manage systems remotely
  • End-User backup products like System Center Data Protection Manager can backup files from remote systems


DirectAccess benefits the end-user by simplifying the remote experience. They don’t need to launch a VPN application. Instead, when they receive an email containing a hyperlink to a resource located on the intranet, it simply works.

DirectAccess makes financial sense because it is already included inside each Windows Server 2008 R2 license. You can therefore, over time, reduce your 3rd party VPN license and support costs by migrating clients to this native VPN technology.

Performance Comparison with PPTP VPN Technologies

In a head to head test between DirectAccess’s Teredo adapter and PPTP VPN, DirectAccess was 16% faster. The DirectAccess IP-HTTPS adapter was significantly slower than PPTP, but offers the benefit of being more firewall friendly because many firewalls are configured by default to block the IP protocol used by PPTP – Generic Routing Encapsulation (GRE) – IP Protocol 4, and TCP 1723.

Teredo DirectAccess 3.39 Mbits/sec
IP-HTTPS DirectAccess 1.37 Mbits/sec
PPTP (Watchguard x1250e) 2.87 Mbits/sec
6to4 DirectAccess n/a*


*The 6to4 adapter is reportedly Faster than Teredo and I will update this blog once I test its performance.

Note: these tests were performed on a UAG/DA server w/6GB RAM. Your results will vary.  I used iperf to perform the throughput testing.

Better together with Microsoft ForeFront Unified Access Gateway

Microsoft’s Unified Access Gateway 2010 greatly simplifies the deployment of DirectAccess (DA).

There are four very simple and straight forward wizards to configure UAG DirectAccess.



UAG enhances DA by enabling High Availability through load balancing. Without UAG, DA would be a single point of failure.

UAG is also required if you have not completely deployed Windows 7, as it provides an SSL VPN application for legacy clients [see system requirements section below].

If you have not completely deployed IPv6 internally, you will also need UAG so that your clients can access IPv4 resources internally. UAG performs NAT64/DNS64 to translate IPv6 packets to internal IPv4 resources.

If you have non-domain joined computers, you’ll need UAG to compliment DirectAccess. It comes with an SSL VPN client that can be used by non-domain joined computers.

UAG comes with ForeFront Threat Management Gateway (formerly ISA server) firewall to protect DirectAccess. Because DirectAccess requires a server with two NICS, one leg on the public internet and the other on the internal segment, it is wise to protect it. UAG/DA can be deployed behind your existing firewall (see this technet article for firewall port requirements). Even if you don’t use UAG, in a pure DA environment, it is

DA is supported in a virtual environment [according to this forum post].

The DirectAccess + Forefront UAG server can also be configured to integrate with Microsoft Network Protection Server (NPS) (a role also built-in to Windows Server 2008/R2) to diagnose if the client trying to access the network is healthy or not. NPS is beyond the scope of this blog article but more information on NPS can be read here.


Read more about UAG here:

DirectAccess Connectivity Assistant (DCA)

This free Solution Accelerator from Microsoft runs in the taskbar and informs end-users of their DirectAccess connectivity status. If there are any problems, it generates a debug log that can be emailed to IT. Very handy! Visit the Download Center to get more technical information and download the DirectAccess Connectivity Assistant

DCA provides the following benefits:

  • Lets mobile users know their connection status: DCA provides an indicator in the notification area that keeps mobile users informed of their connectivity status with an organization’s intranet.
  • Reduces the number of support calls: DCA has built-in remediation tools that help mobile users solve connection problems on their own, without calling the help desk.
  • Reduces the duration of support calls: If support is needed, DCA helps mobile users provide IT staff with key diagnostics to zero in on the source of a problem, so IT can resolve the issue faster and get users back to work.
  • Helps users stay productive: Because DCA helps IT solve connection problems faster, mobile users have more reliable access to network-based resources, and can stay more productive.

After DCA is set up on your computer, one of the following icons appears in your notification area to inform you of your connectivity status:

Notification area icon

What this means


Good DirectAccess connectivity


Action required


DirectAccess malfunction

Download the DirectAccess Connectivity Assistant

Pilot before Production

Run a pilot in your IT Department first, and then extend it to a group of 25 users representing each business unit within your organization. The goal is to discover and resolve as many connectivity issues as possible. For example, we found that Microsoft Office Communicator requires its names to be added to the Name Resolution Policy Table (NRPT). See this technet blog post for more information.

Tom Shinder put together helpful lab guide to build out a DA test lab here.  If you’re skeptical about deploying an IPv6 solution without completely understanding how it works, read this post from Tom.

Why you shouldn’t throw away your VPN solution just yet

Tom Shinder works for Microsoft in the UAG Direct Access/Anywhere Access Group. He wrote a fantastic blog article on why DA is not a replacement for VPN.  He says the vision of DirectAccess is to keep the DirectAccess client continuously connected to the intranet. The point he makes is that you may not want partners to always be connected. Your IT Department may want to connect from personal/unmanaged workstations to do work remotely. And as I write that, I can think of IT Departments who would probably go exclusively with DirectAccess to prevent unmanaged machines from connecting, especially since DA and easily integrate with NAP to verify the health of a client (virus definition level, patch status, etc).

If I properly understand how UAG works, then the UAG component of a DA + UAG solution *can* replace your traditional VPN solution because it provides a competitive SSL VPN client that can replace whatever you’re using today.

Each of the DirectAccess adapters (6to4, Teredo, IP-HTTPS) have connectivity limitations that should be evaluated before ripping and replacing an incumbent VPN solution.

If the DA client has a public IP address, it will first attempt to use the 6to4 tunnel adapter. The limitation of the 6to4 adapter is that it requires IP Protocol 41, which many routers and WWAN wireless providers block such as the AT&T Aircard. Samar from Microsoft said in this TechNet forum post that he has seen issues between DA and WWANs "fairly often." The work-around is to disable the 6to4 adapter via group policy or manually, as this forces the DA client to step down to the next fastest adapter, which is Teredo.

If the DA client has a private IP address (ex:,, and outbound access to UDP 3544, then the DA client uses Teredo. If outbound UDP 3544 is blocked, it will fall back on IP-HTTPS as a last resort.

The IP-HTTPS adapter does not work behind proxy servers that require authentication with each connection.  To determine if you are behind this type of proxy, open your Internet browser and browse a public website. You might be prompted for authentication. Open a second Internet browser window or tab and browse a different public website. If you can get to the second website without having to specify authentication credentials, IP-HTTPS should work across the proxy. If you need to enter credentials each time you access a different website, IP-HTTPS might be blocked.

Should you ever decide to change your public IP address range, you’ll need a traditional VPN for users to refresh group policy to get the new DA IP address. Read more about that here.

So how does it work?

A DirectAccess client determines whether it is local or remote. It does this by attempting to locate an internal server that you designate as the Network Location Server (NLS). If it cannot reach the NLS, then the client attempts to create an IPSEC tunnel to the DA server using one of the adapters described above (6to4, Teredo, IP-HTTPS). The adapter is selected based on whether the client has a public or private IP address.

In an over-simplified description, traffic is directed through the DirectAccess tunnel when the following four conditions are met:

1) Client is not able to resolve the designated Network Location Server

2) Client is attempting to resolve a name that matches the Name Resolution Policy Table (NRPT).

3) Client’s Windows firewall profile does not detect a Domain Profile. Windows Firewall must be enabled and the profile must be detected as public or home before the tunnel will come up.

4) Client’s machine account is a member of a security group filtered by the Group Policy Object containing the NRPT.

If you noticed the last item, name resolution is the method a DA client uses to perform split tunneling. For example, if a name lookup does not match a name in the NRPT, or if the name is mentioned and explicitly listed to ‘bypass proxy’, then all other traffic will use the client’s primary DNS server for name resolution and therefore not go through the DA tunnel for subsequent IP communication. This is important to understand, because DA clients cannot ping an intranet IPv4 IP address – instead, they must rely on the DNS64 functionality in UAG to return a translated IPv6 address before communication can happen.


But is it secure?

Out of the box, it supports multi-factor authentication. A remote machine must have a computer certificate issues by the internal enterprise certificate authority. It uses windows integrated user authentication via Kerberos. You can have it require smart-card authentication. If you so desire, you can restrict communication to only certain internal servers. You can have it integrate with NPS to perform health checks on your patch level and antivirus definitions. In all, it is much more secure than most commercial solutions.

Other Tips

You can assign a public certificate to the IP-HTTPS adapter. This simplifies the deployment so that you do not need to publish the CRL.

Then, you can disable the 6to4 and Teredo adapters to force end-users to always use the IP-HTTPS adapter. In my opinion, this simplifies the overhead of maintaining a solution as complex as DirectAccess.


System Requirements for DirectAccess

  • Windows 7 Enterprise or Ultimate (domain joined)
  • Windows Server 2008 R2 (domain member) with two public IPv4 addresses (cannot be NAT’d) . It can be a virtual or physical host.
  • IPv6 internally deployed (or use UAG if you have not deployed IPv6 internally). They do not need to be global ipv6 addresses – you can get away with just having the ipv6 box checked and not configure a single global ipv6 address. DA will function as an ISATAP router and convert those addresses into 2002: addresses that your clients can resolve.
  • UAG is only required if you have internal IPv4 resources that your clients need to communicate with, if you have non domain joined machines, if you need to load balance DA, if you have not completely rolled out Windows 7, if you want the TMG firewall to protect your DA Server, if you allow vendors/partners to VPN into your network, and if you want to make DirectAccess easy to manage. As you can see, you should nearly always deploy UAG with DA! Make sure you deploy it with Update 1, as it resolves some critical bugs.

Complete requirements can be found here:


DirectAccess + TMG

DirectAccess + ForeFront UAG