Windows NT 4.0 included an implementation of the Point to Point Tunneling Protocol (PPTP) for both the NT4 Workstation and NT4 Server products, with a client for Windows 95 OSR2, and PPTP is still supported in Windows and other operating systems. Virtual Private Networking (VPN) technologies have evolved since then. In fact, could they have perhaps evolved so much that they don’t exist any more?
While 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 VPN technology, these operating systems still support 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, and how can it be useful as an alternative to those older VPN technology choices?
Why does Microsoft claim that DirectAccess is not a VPN technology? To understand this, let us first look at what some of the other VPN technologies are, then the similarities and differences between these and DirectAccess, and the distinction should become clear.
Many hardware and software vendors offer VPN implementations, yet from a Microsoft perspective, the PPTP, L2TP, and SSTP VPN solutions in Microsoft Windows are coupled with Routing and Remote Access Services (RRAS) on the server side, and dial-up networking (DUN) on the client side. The way most people use these VPN technologies in Windows, the end-user on the client machine either explicitly “dials” into the VPN server after they have logged on, or perhaps as a part of the logon process. The first real distinction between these technologies and DirectAccess is that this supposedly non-VPN 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.
The ramifications of this, and if we merely focus on the benefits of this for a moment, are significant with respect to applying Active Directory Domain Services (AD DS) based Group Policies to such client machines, applying updates via Windows Update Automatic Updates (WUAU) and Windows Server Update Services (WSUS), and ability to perform other forms of remote administration of these client systems at any time. We do not have to wait for a user to log on and dial into the VPN in order to have centralized management ability and control over the constituent systems. To Microsoft, perhaps this is construed as a key distinction which casts DirectAccess as a non-VPN technology, however from my humble perspective, as it has always been possible to have a startup script dial into a VPN connection using particular user credentials, I’m not 100% clear why they would consider that a distinction other than a variation from the average end-user expectation of how VPNs are typically used. To me it doesn’t make DirectAccess a non-VPN technology, but that’s just my opinion.
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.
Although, like with many new technologies, there are requirements specific to DirectAccess that are not needed for other VPN technologies, establishing a DirectAccess Server based on Windows Server 2008 R2, the necessary infrastructure, and as many DirectAccess clients as you need, running Windows 7 Ultimate or Enterprise, is a fairly straightforward endeavor. The benefits are many for this always on VPN technology, primarily the ability to support always manageable systems in remote offices, home offices, and in mobile Windows 7 machines the field. DirectAccess allows private, controlled access, over tunneled virtual network interfaces of Windows 7 machines which need to be connected into their main office whenever they have public Internet access available. To VPN or not VPN, is not really a relevant question anymore. What’s in a name? Beside the fact that you might be used to dialing up your VPN connection after you log on, whereas DirectAccess is always on, does it really matter whether you call it a VPN technology or not?