Delving into DirectAccess (without Drowning in IPv6)

 

object001

One of the great synergistic cofeatures of using Windows 7 in a Windows Server 2008 R2 network infrastructure is DirectAccess, which Microsoft claims is not a Virtual Private Networking (VPN) technology. These operating systems still support older VPN technologies including PPTP, as well as VPN cousins L2TP (as of Windows 2000) and SSTP (as of Vista SP1 and Windows Server 2008). Just how does DirectAccess compare to those other technologies, such that it can be useful as an alternative to those older VPN technology choices?

Why does Microsoft claim that DirectAccess is not a VPN technology? The technical distinction is that DirectAccess technology is always on. In other words, DirectAccess clients connect into their DirectAccess server as soon as the client machine starts up and the underlying physical network connection(s) become available. Other than that, and marketing spin, it is a VPN technology.

Let’s look a bit deeper at DirectAccess to better understand what it is and is not. To quote Microsoft TechNet “DirectAccess, introduced in the Windows® 7 and WIndows Server® 2008 R2 operating systems, allows remote users to securely access enterprise shares, web sites, and applications without connecting to a virtual private network (VPN).” <http://technet.microsoft.com/en-us/network/dd420463.aspx> More specifically, the DirectAccess client is a feature of the Windows 7 Ultimate and Enterprise editions. Like PPTP, L2TP, and SSTP, DirectAccess also uses tunneling to carry Internet Protocol (IP) traffic encapsulated in the Point to Point Protocol (PPP), however the further tunneling details of these four technologies (PPTP, L2TP, SSTP, DirectAccess) are what makes them unique. There are two aspects to the tunneling distinctions, namely (a) tunnel negotiation, establishment, teardown, and administration, as well as (b) tunnel encapsulation and security for the content – the network traffic carried in IP/PPP across the tunnel.

One of the critical components of DirectAccess is the use of the Internet Protocol version six (IPv6) as the internetworking protocol carried by the tunnel, as well as in two of the three options for how DirectAccess implements the tunnel itself. Two IPv6 to IPv4 interoperability and coexistence technologies which can be used with DirectAccess are 6to4 and Teredo. With 6to4 tunneling, IPv4 traffic is tunneled over IPv4 networks such as the public Internet and private IPv4 networks. However, 6to4 tunneling does not work particularly well with IPv4 network address translation (NAT), luckily we have one of the other IPv6 interoperability technologies, Teredo, as another choice for DirectAccess tunnel foundations. Teredo, named after the “shipworm” mollusk that is known for boring holes into wooden ship hulls, is designed to provide IPv6 over IPv4 tunneling like 6to4, but with the advantage of boring through routers which do NAT. The third choice for the IPv6 over IPv4 tunneling of DirectAccess is use of IP-HTTPS, which utilizes the Hypertext Transfer Protocol (HTTP) over the Secure Sockets Layer or the standardized Transport Layer Security (SSL/TLS), and like regular https for web site access, uses TCP port 443 for the server side of the connection. Whether 6to4, Teredo, or IP-HTTPS is used for DirectAccess, the datagrams tunneled within such conduits is IPv6.

Like any typical VPN server, the DirectAccess server needs to have a publicly addressable network interface (the public or untrusted side) and a separate internal network interface (the private or trusted side). Again, the DirectAccess Server implementation is in Windows Server 2008 R2. An additional requirement which Microsoft specifies that is not universal to all VPN technologies is that the public side of the DirectAccess server have two consecutive public IPv4 addresses configured and accessible. Like many L2TP implementations which use IPsec with public/private key pair authentication, and SSTP which uses SSL/TLS with public/private key pair authentication, so too does DirectAccess require a public key infrastructure (PKI). The baseline requirement is merely to have public key certificates issued to the computers involved (client and server). A variation on the public key certificate for the computer is to issue a smart card which is used in the client. If Network Access Protection (NAP) is also required in your environment, then the public key certificates issued to the computer would be health certificates issued from your NAP authority.

Another Microsoft-specific requirement which is hopefully not too much of a surprise now that Active Directory is over ten years old, is that at least one AD DS domain controller and DNS server running on Windows Server 2008 SP2 or Windows Server 2008 R2 is required in the internal network on the trusted side of the DirectAccess server.

With these technical requirements in mind, what is most important to understand is to not be afraid of IPv6. First of all, IPv6 implementations have been running in production environments and the public Internet for over 10 years. More to the point, with respect to DirectAccess, is that Microsoft took great care in the design of DirectAccess so that you do not need to transition your networks to be fully IPv6-capable in order to use DirectAccess. If your organization is using modern versions of Windows, the requirements for DirectAccess are actually quite modest. If you’re looking for an always-on VPN-like solution for remote client connectivity, consider setting up a DirectAccess testbed and assessing its effectiveness in your organization.

Leave a Reply

Your email address will not be published. Required fields are marked *