LifeinTECH

DirectAccess is a new feature in Windows 7 and Windows Server 2008 R2 that enables remote users to securely access shared folders, web sites, and applications without connecting to a virtual private network (VPN). The main advantage this has over traditional VPN solutions, is that it is integrated into the Operating System so that whenever you have an Internet connection available, Windows will automatically attempt connect to your corporate network. If your connection drops or you change location, Windows will continuously attempt to reconnect on your behalf.

With the release of Windows 7 in October 2009, I have been eagerly waiting for some new information on DirectAccess. Unfortunately it seems like the whole industry is waiting for the same thing and the only company to have delivered DirectAccess so far is Microsoft. As a result, myself and a colleague have setup a DirectAccess test environment to help us better understand the product and see if it lives up to Microsoft’s bold claims.

The setup was configured using the Microsoft DirectAccess test lab setup guide. The initial setup is for simulation purposes only and does not connect over the Internet, however it does validate the architecture, configuration and prove the concept. The diagram below shows an overview of the test setup:

In summary:

• DA1 (DirectAccess Server), DC1 (Domain Controller) and APP1 (Application Server) are all directly connected to the corporate network (10.0.0.0/24).

• INET1 and NAT1 simulate the Internet, the INET1 server provides DNS and DHCP services, while NAT1 simulates a home broadband router that performs network address translation.

• DA1 (DirectAccess Server) also has a connection to the Internet as it acts as your termination point (or concentrator in the Cisco world).

• A client machine that can connect directly to the corpnet (simulating work LAN), Internet (simulating a direct Internet connection) or homenet (simulating your home Internet connection).

The video below shows the test lab setup and demonstrates connecting a client to the corporate network and then directly to the Internet. When connected to the Internet you can see DirectAccess seamlessly establish the connection with the corporate network allowing you to access the Intranet and file shares as if you were connected locally.

Please Note: The video was shot on an iPhone and as a result the sound levels are not great. If you are having issues please connect headphones.

The next video adds the NAT1 server which simulates a user connecting from their home through a standard Internet router. During this demonstration we also look at Teredo tunnelling and IP-HTTPS which are key protocols that allow DirectAccess to work.

Teredo tunnelling is designed to grant IPv6 connectivity to nodes that are located behind IPv6-unaware NAT devices (the majority of home Internet routers). It defines a way of encapsulating IPv6 packets within IPv4 UDP datagrams that can be routed through NAT devices and on the IPv4 Internet, allowing DirectAccess to connect.

In certain situations Teredo tunnelling will still fail due to specific ports being blocked. If this happens, Windows 7 will attempt to use the IP-HTTPS protocol which uses SSL on TCP port 443 to connect the DirectAccess client to a DirectAccess server on the edge of your corporate network.

Without these two protocols DirectAccess would not be able to establish a connection in common real world scenarios such as behind a device performing NAT or from networks with tight port restrictions on their network edge (such as other corporate networks).

Please Note: The video was shot on an iPhone and as a result the sound levels are not great. If you are having issues please connect headphones.

That concludes this stage of our testing. To summarise, in this simulation we have successfully demonstrated Microsoft DirectAccess establishing a connection when connected directly from the Internet and from behind a device performing NAT, such as a home Internet router. We have also simulated the use of IP-HTTPS where specific ports are blocked and Teredo tunnelling is unable to operate.

This testing is just the beginning. The next stage is to move this simulation into a real world scenario, where the DirectAccess server is actually connecting over the Internet. I also intend to post a follow-up showing the individual configuration on each server (however this information can already be found in the Microsoft DirectAccess test lab setup guide.

It is still too early to provide a verdict as to whether DirectAccess will be a success, however as testing progresses we should start to unravel its secrets and understand how it stands up to everyday use.