DirectAccess in Windows Server 2008 R2 (part 1)

• The need for the user to manually connect to the VPN.

• The delay the user experiences when connecting to the VPN while health checks are completed during the connection process.

• The need for the user to reconnect manually if an established VPN connection is lost.

• The slow performance when all traffic (intranet and Internet) is routed through the VPN connection.

These challenges can cause users to limit the use of traditional VPN solutions. DirectAccess has been designed from the ground up to address those challenges. DirectAccess hides all the connection processes from the users and intelligently routes intranet versus Internet traffic, thereby alleviating the challenges of traditional VPNs. It connects as soon as the computer starts up and conducts the health checks, rather than when the user is logging in. The connection process is transparent to the user and the user never needs to explicitly connect to DirectAccess. Finally, DirectAccess has built-in options to control how DNS requests are handled, effectively bifurcating the Internet and intranet traffic to avoid burdening the remote access connection and improving performance.

DirectAccess creates an encrypted point-to-point tunnel from a remote user—in this case, specifically a remote user on Windows 7—to the internal “enterprise” network. The difference is that the connection is transparent to the user. Once configured, the computer will automatically connect to the office from any available Internet connection. The user experience is almost identical to being in the office. In addition, through the use of the Windows Server 2008 R2 NPS server, remote-connected clients can be securely managed similarly to internal client systems.

DirectAccess uses IPv6, IPSec, and certificates to establish secure connections from the DirectAccess clients to intranet resources via the DirectAccess server. To traverse public IPv4 networks, DirectAccess uses IPv6 transition technologies such as ISATAP, Teredo, and 6to4.

DirectAccess has some specific requirements, as follows:

• The server running Windows Server 2008 R2 needs to have two network cards: one attached to the intranet and one attached to the Internet.

• The Internet network card must have two consecutive public IPv4 addresses.

• The Intranet resources and applications must support IPv6.

• The DirectAccess clients need to be running Windows 7; older clients are not supported.

• A domain controller and DNS server that the systems are connected to need to be running Windows Server 2008 SP2 or Windows Server 2008 R2.

• A PKI needs to be available to issue certificates with a published Internet available certificate revocation list (CRL).

These requirements are somewhat stringent and might prevent many organizations from deploying DirectAccess. However, for an organization with an up-to-date infrastructure, servers, and clients, DirectAccess can be an excellent solution.

DirectAccess and IPv6

DirectAccess is designed on top of IPv6 and requires that all endpoint devices support IPv6. It is one of the first services to require this modern protocol.

DirectAccess is most likely to be deployed in an IPv4 world, given the prevalence of IPv4 on the Internet today. This creates an IPv4 gap (shown in Figure 1) across which IPv6 devices like DirectAccess clients need to communicate.

Most organizations will need to use IPv6 transition technologies to bridge the IPv4 gap from their IPv6 enlightened devices to communicate. This, in effect, routes the IPv6 communications through the IPv4 protocol stack, as shown in Figure 2. The packets traveling down the IPv6 protocol stack take a sharp turn and move across the protocol stack to the IPv4 protocol stack, allowing them to transit the IPv4 network. On the other side, the same packets come in via the IPv4 protocol stack, but are routed to the IPv6 stack.

Figure 2. Bridging the IPv4 gap with transition technologies.

Communications between IPv6 devices like DirectAccess clients over IPv4 networks is accomplished with IPv6 over IPv4 tunneling. In tunneling, the IPv6 packets are encapsulated in an IPv4 packet by the source device and routed through the IPv4 network. When the encapsulated packet arrives at the boundary between the IPv4 and IPv6 networks, the IPv4 encapsulation is stripped off and the IPv6 packet continues on its way. The most common tunneling protocols are ISATAP, 6to4, and Teredo.

For organizations, the IPv6 tunneling protocols are used for the following purposes:

• ISATAP— This protocol is used to automatically assign IPv6 addresses within the organization’s IPv4 intranet.

• 6to4— This protocol is used to automatically assign IPv6 addresses and route across the public IPv4 Internet.

• Teredo— This protocol is used to automatically assign IPv6 addresses and route across the public IPv4 Internet to devices behind Network Address Translation (NAT) firewalls.

For organizations that have not deployed IPv6 natively, Microsoft Windows Server 2008 R2 and Windows 7 support ISATAP, 6to4, and Teredo transition protocols. However, even while DirectAccess clients are using IPv6 transitional technologies like Teredo or 6to4, it is ultimately communicating from IPv6 clients to IPv6 hosts.

Internally, DirectAccess can use Network Address Translation-Protocol Translation (NAT-PT) devices, which can be used to provide access to IPv4 resources. Resources that don’t support IPv6 natively can be accessed through the use of a Network Address Translation-Protocol Translation (NAT-PT) device. Microsoft Windows Server 2008 R2 does not currently include that capability, so a third-party device would be needed for this functionality.

For organizations that have not deployed IPv6, the deployment of DirectAccess is an excellent project to test the IPv6 waters with. The infrastructure can be deployed in parallel with existing remote access solutions and without impacting the existing IPv4 addressing scheme, providing IT personnel with a chance to learn IPv6 and its integration with IPv4 in a low-impact production setting.

A Tale of Two Tunnels

The DirectAccess client establishes two tunnels, which are key to the versatility of this method of remote access. These tunnels are IPSec Encapsulating Security Payload (ESP) tunnels that are authenticated with certificates and encrypted to ensure the confidentiality. These tunnels are as follows:

• Computer tunnel— The computer tunnel is established first when the DirectAccess client starts up. This tunnel is authenticated with the computer certificate only and provides access to the intranet DNS and domain controllers. This tunnel is also used to download the computer group policy and request user authentication.

• User tunnel— This tunnel is authenticated with the computer certificate and the user credentials and provides access to the intranet resources. This tunnel is used to download user group policy as well.

Both these tunnels are established transparently to the user. The user does not have to present credentials above and beyond the normal Windows logon to establish remote access. The two tunnels are shown in Figure 3.

These tunnels allow for the transparent establishment of remote access, essentially allowing the computer to connect to the intranet even when no user is logged on. This allows the DirectAccess client to receive Group Policy remotely and be managed by the management servers in the intranet. When a user logs on, they are authenticating to the intranet and, thus, ensuring that users are subject to the latest requirements, password changes, and policies. In contrast, other VPN solutions typically have users authenticating using cached credentials against the local machine and then establishing the remote access connection.