A couple of weeks ago I was fortunate to be offered a place on a two day class at Microsoft to learn about the DirectAccess functionality of Windows 7 and Server 2008 R2. The class was run by Fernando Cima from MS in Brazil (who it has to be said really knows his stuff).
For many years now private company networks have been completely separate from the hostile environment of the Internet. This separation is achieved through the use of firewalls etc, and in many cases internal networks use private IP address ranges that can’t be directly addressed from the internet.
Whilst this separation provides a level of security, it does make life difficult for mobile workers, after all they’re on the Internet wanting to gain access to the very resources company’s want to protect. Many organisations use solutions like VPN’s, Citrix and application publishing (for example Outlook Web Access published through a reverse proxy) to get around these limitations and make services available to remote workers.
These solutions are definitely useful, but the user experience for mobile workers is often less than ideal. To maintain security they’ll almost certainly have to logon to these remote services separately, probably using complex passwords or two-factor authentication like RSA SecurID. It’s hardly seamless. Using a VPN probably also means that any traffic between the laptop and the Internet is routed though the VPN, into the company network, out of the company Internet connection and back again. Again, not exactly ideal (though split-tunnelling can help).
What’s more, supporting remote clients is often a support nightmare. Devices not on the network are hard to manage. Using a VPN they are only accessible if and when the user launches the VPN. Whether the connection is up and running long enough for patches to download etc. is often down to chance.
So all in all there’s a lot of room for remote access solutions to be improved. This is where DirectAccess tries to help. It provides remote clients with seamless access to both the Internet and the internal network (intranet). If the remote client has internet access, it automatically has access the intranet and the services within it. No client software to launch, no additional authentication nothing. Sounds good eh?
So how does it work… well the first thing to note is that DirectAccess isn’t a fancy new product in its own right – it’s really just a clever implementation of IPv6 and IPSec. There is however a DirectAccess server role, and a wizard to set the whole thing up.
At a high level it makes sure that both the client computer and the Intranet resources are globally addressable, and secures communication between them. Of course to do this there are a number of problems to overcome:
Addressing
As mentioned, internal networks often use private address ranges, and even if they didn’t there simply aren’t enough IPv4 addresses available for companies to use globally unique addressing.
Fortunately IPv6 is here to save the day… (this is the scary part). IPv6 provides globally unique addressing, allowing the client and intranet services to address each other. The techie among you are probably now thinking about how your networks are all IPv4 and that this is never going to work.
From Windows Vista onwards, the IP stack in Windows has natively supported IPv6, and enables it by default. In fact, Windows now favours IPv6 and will use it to communicate with other Vista/2008/7 nodes if it can. So there’s a fair chance that some of your computers have an IPv6 address already.
In many cases of course computers will be sitting on an existing IPv4 networks. IPv6 traffic would therefore need to traverse these older networks to be of any use. To achieve this IPv6 can be encapsulated within IPv4 packets. Windows also now supports a number of protocols for achieving this natively, and will automatically encapsulate IPv6 should it determine that there is IPv4 connectivity between two IPv6 nodes (it can also be forced). On an Intranet the ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) is used to achieve this, and is enabled when DirectAccess is setup. Older IPv4 based resources (for example Window Server 2003 and earlier) can be accessed through the use of IP translation devices such as Network Address Translation-Protocol Translation (NAT-PT).
The other area where IPv6 traversal over IPv4 networks has to be considered is over the internet, which is IPv4, and on the clients local network which is likely to be IPv4. DirectAccess clients will attempt to use traversal technologies to gain access to the DirectAccess server, in these cases either 6to4 or Teredo depending on whether the client has a public internet address or is on a NAT’ed network. Again this is automatic and handled by the Windows IP stack. As a last resort, if 6to4 and Teredo traffic is blocked, a new protocol IP-HTTPS is used to encapsulate IPv6 packets inside HTTPS.
So in short, you should be able to use IPv6 for DirectAccess with only minimal work to the underlying network. MS themselves are very clear that IPv6 is a long term goal, and have provided a heap of technologies in Windows to help deal with a long transition.
Security
If both your remote clients and your internal services are globally addressable, security is going to be a big concern. DirectAccess uses the IPSec features of IPv6 to authenticate the client connecting to the DirectAccess server, and protect the traffic that passes between them.
Computer authentication certificates can be either issued from a central CA in the domain to validate that the remote client is a company asset, or can be issued by the health authority within a Network Access Protection (NAP) environment. In that case computers are validated as being ‘healthy’ before being granted access.
Name Resolution
Using DirectAccess clients effectively have access to both the Internet and the intranet. You therefore need to ensure that traffic intended for the intranet goes there, and not out to the Internet. Windows 7 does this using a Name Resolution Policy Table. This table contains entries for internal namespaces and corresponding internal DNS servers. When an application wants to access a resource, the resources name is compared to entries in the NRPT, if there’s a match the internal DNS server is used to resolve the name, if not the Internet connections DNS server is used. In this way traffic is routed to the correct location.
So at a high level that’s how direct access works. There’s a lot more to it than that, and I’ll try to post more over the next few days. It’s a pretty complex thing to deal with – my head hurt after the two day class having struggled to take it all in. I’ve never done anything with IPv6, so that was a hell of a learning curve, but once to you go though is a few times is make a lot of sense.
IPv6 is probably going to be Microsoft’s biggest obstacle in gaining traction with DirectAccess, many people I’ve spoken to about is run away when you point out that IPv6 is required. Having worked though the implementation in a few labs however it’s not all that bad. Whilst there are things you would want to do before enabling IPv6, it’s far less work than I though it would be – at least to get to a point where DirectAccess works.
Do the benefits of DirectAccess make it worthwhile? Well it’s certainly a great solution. Once it’s working remote clients are on the internal network, so communication is bi-directional and remote clients can not only access internal resources, but can be accessed from those internal resources for management and support. Group policy applies as the computer starts up and users logon, patches apply and applications can be delivered. For organisations with large numbers of remote users that’s are pretty compelling functionality.
Whilst IPv6 might be perceived as an obstacle for DirectAccess, DirectAccess is probably the first ‘killer app’ for IPv6.
![IPv6TransitionTechnologies1[1]](http://refraction.co.uk/blog/wp-content/uploads/2009/10/IPv6TransitionTechnologies11.jpg "IPv6TransitionTechnologies1[1]")
