Joseph Davies

Parts of this article are based on prerelease code. All information herein is subject to change.

Contents

Protected Traffic across the Internet
End-to-End Addressing and Connectivity
Bidirectional Connectivity and Remote Client Management
Firewall and Web Proxy Traversal
Determination of on-Intranet vs. on-Internet
Separating Intranet from Internet Traffic
Summary

To provide intranet resource availability to remote users, typical organization networks today employ some sort of edge network containing servers for various types of remote access. These servers can be virtual private network ( VPN ) servers or concentrators, Terminal Server ( TS ) Gateway servers, or a variety of application edge servers, such as Microsoft's Outlook Web Access (OWA).

The edge network exists to separate the intranet from the Internet because the Internet is an extraordinarily hostile networking environment. An IT architect who directly connects his or her intranet to the Internet without this separation—and sufficient security systems—will soon be looking for another line of work. However, the separation introduces complexity for the remote user.

If directly connecting the intranet to the Internet for seamless access to both intranet and Internet resources for remote users is not a practical option, then the solution lies in seamlessly connecting the remote user to both the intranet and the Internet.

Current remote access VPN solutions, including Routing and Remote Access in Windows Server 2008, attempt this solution through a user-initiated Layer 2 connection to the intranet. However, remote access VPN connections are hardly seamless because they require user action to connect and reconnect. Moreover, for most VPN deployments, the VPN client computer is either connected to the Internet (when the VPN connection is not active) or connected to the intranet (when the VPN connection is active), but not both simultaneously.

It is possible to address the issue of concurrent Internet and intranet access for VPN connections by sending Internet traffic through the intranet or by configuring split-tunnel routing so that Internet and intranet traffic are separated. However, sending Internet traffic through the intranet makes Internet access for connected VPN clients slow, and setting up and maintaining split-tunnel routes can be administratively difficult.

Another issue for current VPN solutions is that the remote computer is connected to the intranet only intermittently. The model of user- initiated connections makes it difficult for IT administrators to manage remote computers with the latest updates or security policies. Remote computer management can be mitigated by checking for and requiring system health updates before completing the VPN connection. However, such requirements can add substantial wait times to the VPN connection process.

Now a new feature of Windows 7 and Windows Server 2008 R2 called DirectAccess brings us a step closer to the solution; remote clients have seamless and concurrent access to both intranet and Internet resources without adding ongoing administrative overhead and without sacrificing performance or security.

With DirectAccess, you can reduce your dependence on remote access and application edge servers, leading to the notion of the thin edge network. For example, your VPN infrastructure can be reduced because DirectAccess clients can now directly access the resource servers on the intranet. As Figure 1 shows, DirectAccess can transform your edge network. To achieve this, however, a number of engineering problems had to be solved.

fig01.gif

Figure 1 Transforming Your Edge Network with DirectAccess

Protected Traffic across the Internet

DirectAccess uses Internet Protocol security ( IPsec) in tunnel and transport mode to authenticate the computer that is connecting and to protect the traffic that is being exchanged with the DirectAccess server over the Internet. Existing VPN solutions also use IPsec encryption. You can specify IPsec protection for computers running Windows 7 with connection security rules, which can be centrally configured through Windows Firewall with Advanced Security Group Policy settings.

End-to-End Addressing and Connectivity

Due to a lack of public IPv4 address space and the reuse of the private IPv4 address space by ISPs and intranets, providing end-to-end connectivity for remote clients with globally unique addresses is not possible with IPv4. The solution is IPv6, which provides globally unique addressing and simplifies the separation of Internet and intranet traffic. IPv6 connectivity is a requirement for DirectAccess. The only resources that DirectAccess clients can access are those that are reachable with IPv6. Therefore, your intranet must be IPv6-capable, either natively or by deploying the Intra-Site Automatic Tunnel Addressing Protocol ( ISATAP ). Alternatively, DirectAccess clients can reach IPv4-only resources on your intranet through a NAT64 device.

Directing Traffic

Let's suppose that for the fictional Contoso Corporation, the DNS namespace for all intranet resource names is corp.contoso.com, with intranet DNS servers FDA5:2C09:1F3C:E215::1 and FDA5:2C09:1F3C:E215::2.

In this case, the NRPT for Contoso's DirectAccess clients would contain the entry: namespace is .corp.contoso.com and DNS servers are FDA5:2C09:1F3C:E215::1, FDA5:2C09:1F3C:E215::2. Namespace

When a user runs Microsoft Outlook and attempts to connect to the EXCHNG071 email server, the TCP/IP stack will append the domain suffix for the computer (corp.contoso.com.) to the e-mail server name to get exchng071.corp.contoso.com. This name is compared against the NRPT. Because the name matches the entry for .corp.contoso.com, the DirectAccess client sends the DNS name query request to the intranet DNS servers at FDA5:2C09:1F3C:E215::1 and FDA5:2C09:1F3C:E215::2. Microsoft Outlook uses the IPv6 addresses that are returned in the DNS name query response and directly connects to its intranet Exchange server.

Let's assume that during the transition of users to Windows 7 and DirectAccess, the Contoso IT department has kept their OWA servers in their edge network. When a user on a DirectAccess client uses Internet Explorer to access the OWA server at the address https://exmail.contoso.com/exchange/, the TCP/IP stack will attempt to resolve the DNS name exmail.contoso.com. This name is compared against the NRPT. Because the name does not match the entry in the NRPT, the DNS name query request is sent to Internet DNS servers and Internet Explorer makes a connection directly to the OWA server in the edge network.

Bidirectional Connectivity and Remote Client Management

A DirectAccess client tries to connect to a DirectAccess server when the computer starts. When the user logs on, a different set of credentials is used for connecting to intranet resources. The key difference with DirectAccess over typical VPN connections is that the DirectAccess client computer is always connected to, registered with, and logged on to the intranet domain. IT departments can now manage remote computers just like intranet-connected computers and install updates, propagate Group Policy settings, and make other changes on an ongoing basis, ensuring the system configuration and health of remote computers.

Firewall and Web Proxy Traversal

Because IPv6 is the initial Layer 3 transport and most remote computers are communicating across the IPv4 Internet, a DirectAccess client computer will attempt to use the 6to4 and Teredo IPv6 transition technologies to communicate with the DirectAccess server. However, Web proxy servers and some firewalls will not forward 6to4 and Teredo-encapsulated traffic. In this case, the DirectAccess client uses IP-HTTPS, a new protocol in Windows 7 and Windows Server 2008 R2 that tunnels IPv6 packets inside an IPv4-based HTTPS session.

Determination of on-Intranet vs. on-Internet

A DirectAccess client uses a network location server that is reachable only with a direct connection to the intranet, to determine whether it is connected to the intranet. When a DirectAccess client starts up, it attempts to connect to a specified URL on the network location server. If the Web page for the URL can be successfully obtained, the DirectAccess client is on the intranet and DirectAccess is not used.

Separating Intranet from Internet Traffic

As previously described, some VPN solutions use Network layer routing table entries to separate intranet from Internet traffic. DirectAccess solves this problem in the Application layer through more intelligent name resolution and in the Network layer by summarizing the IPv6 address space of an entire organization with a single IPv6 address prefix. Rather than directing traffic solely based on a destination address, DirectAccess clients also direct traffic based on the name needed by the application. DirectAccess clients use a Name Resolution Policy Table ( NRPT ) that contains DNS namespace entries and a corresponding set of intranet DNS servers that resolve names for that DNS namespace.

When an application on a DirectAccess client attempts to resolve a name, it first compares the name with the entries in the NRPT. If there is a match, the DirectAccess client uses the specified intranet DNS servers to resolve the name. If there are no matches, the DirectAccess client uses the DNS servers configured on its Internet connection, which are typically Internet DNS servers. See the "Directing Traffic" sidebar for an example of how this works.

Summary

DirectAccess enables transparent, concurrent intranet and Internet remote access and eases the management of remote computers by combining a number of technologies and components: end-to-end connectivity ( IPv6 ), security ( IPsec), Web proxy and firewall traversal ( IP-HTTPS), location determination (network location server), and traffic separation ( NRPT ) technologies and components. With DirectAccess, you can replace some of your remote access and application edge servers with DirectAccess servers, reducing the number of servers on your edge network devoted to remote access connectivity.

Joseph Davies is a Principal Technical Writer on the Windows networking writing team at Microsoft. He is author or coauthor of a number of books published by Microsoft Press, including Windows Server 2008 Networking and Network Access Protection (NAP), Understanding IPv6, Second Edition, and Windows Server 2008 TCP/IP Protocols and Services.