DirectAccess in Windows Server 2008 R2 (part 2)

End-to-Edge DirectAccess Model

The end-to-edge model of DirectAccess has the DirectAccess client establish an IPSec tunnel to the DirectAccess server. The DirectAccess server then forwards unprotected traffic to the intranet resources. This is the most common form of DirectAccess and closely follows a standard remote access methodology.

Figure 4 shows the end-to-edge connection model. Note that there is a single protected (solid line) connection through the tunnel to the DirectAccess server, which then is forwarded to each of the application servers in three separate unprotected (dashed line) connections.

Figure 4. End-to-edge DirectAccess.

The end-to-edge model requires no IPSec support within the intranet, although the intranet resources still need to support IPv6.

End-to-End DirectAccess Model

The end-to-end model of DirectAccess has the DirectAccess client establish an IPSec tunnel with each application server that they connect to. This ensures that traffic is protected end to end (hence the name) by the IPSec encryption, including while traversing the intranet.

Figure 5 shows the end-to-end connection model. Note that there is a protected (solid line) connection through the tunnel and the DirectAccess server to each of the application servers. This indicates that there are separate IPSec connections to each server, which are protected by encryption not only through the Internet but also through the intranet.

Figure 5. End-to-end DirectAccess.

The end-to-end model requires that each application server run on Windows Server 2008 or Windows Server 2008 R2, as well as use IPv6 and IPSec. There is also some additional overhead for the IPSec connections.

The requirement that all application servers be Windows Server 2008 or higher is a difficult hurdle to overcome in today’s heterogeneous IT environments. This makes the end-to-end model of DirectAccess less common than the end-to-edge model.

Internet Versus Intranet Traffic with DirectAccess

One of the benefits of DirectAccess is the ability to separate the intranet traffic (destined for internal servers) from the Internet traffic (destined for external servers). This conserves the corporate bandwidth for access to corporate resources. By specifying the domains and subdomains for which the DirectAccess server provides access, traffic for those domains is directed through the DirectAccess connection. Other traffic is routed through the default routes and bypasses the DirectAccess connection. This is the highest performance configuration and is the default mode of operation.

However, in some cases, administrators might want to have all traffic route through the DirectAccess connection. Examples of this include organizations that want to control or monitor their client communications or prevent access to certain Internet sites. In these cases, the DirectAccess client can be configured to route all traffic through the DirectAccess connection.

DirectAccess Components

DirectAccess leverages IPv6 technology along with PKI to provide a seamless secure connection to the enterprise network. DirectAccess runs at boot and connects as soon as Internet connectivity is established. There’s no need for a user to configure a VPN client or logon. From an administrative perspective, this technology allows system administrators to manage and monitor remote systems through tools like Microsoft System Center Configuration Manager (SCCM) and Group Policy. DirectAccess finally puts remote workers on equal ground with traditional office employees.

The following list depicts the components found in a DirectAccess deployment:

• DirectAccess server— This is the server that connects to the internal network and the Internet. It has to be running Windows Server 2008 R2 with two physical interfaces: one on the public Internet and one for the internal network. The public interface must have two consecutive public IP addresses assigned.

• DirectAccess client— This is a computer running Windows 7. It must be a domain member with a certificate.

• Corporate IPv6 network— The IPv6 network to which DirectAccess clients will be connecting remotely.

• Certificate server— This server issues the certificates that support the tunnel creation, authentication, and security. This certificate server must have a published certificate revocation list (CRL) that is available internally and externally.

• Network Location Server (NLS)— This is an HTTPS site that serves as the indicator to the DirectAccess client if it is connected to the Internet or the intranet.

• Active Directory and DNS server— This server must be running Windows Server 2008 SP2 or Windows Server 2008 R2. The AD and DNS role can be separate servers, although most organizations will have these services on the same server.

Figure 6 shows the components and their connections.

Smart cards or NAP protection can also be implemented for additional security if desired. In its most simple configuration, DirectAccess requires each client to have a valid computer certificate for authentication to the internal network. This takes the place of a traditional username and password.

DirectAccess requires IPv6 on the internal enterprise network. It leverages conversion technology like Teredo, 6to4, and also the new IP-HTTPS for remote clients using IPv4 to connect to the IPv6 enterprise network. These new technologies are described in the following list:

• Teredo is the most common method for DirectAccess. It allows IPv6 traffic to pass through NAT devices that transition out to an IPv4 public network. A good example is many “hot spot” connections at coffee shops and many home networks.

• 6to4 directly translates IPv6 addresses into IPv4 addresses. If remote clients are directly connected to the Internet and have only IPv4 public IP addresses, 6to4 is the preferred method for connectivity.

• IP-HTTPS is a new protocol in Windows 7 and Windows Server 2008 R2. It tunnels IPv6 traffic over an IPv4 HTTPS tunnel between a DirectAccess client and a DirectAccess server. Although this might seem like the simplest option, it comes at a large performance cost due to network overhead and should be used only as a last resort.

The DirectAccess protocol is very robust and will transparently attempt multiple methods of access to establish a connection.

Network Location Service

The Network Location Service (NLS) is a critical component for the DirectAccess architecture. This is a website that clients attempt to connect to determine if they are currently connected to the Internet or to the intranet. It is the URL of a highly available website in the corporate intranet.

There are two behaviors that would be experienced for the DirectAccess client system. They are as follows:

• If the DirectAccess client can reach the NLS URL, it assumes that it is connected to the corporate network and no further action is necessary.

• If the DirectAccess client cannot reach the NLS URL, it assumes that it is not connected to the corporate network and then begins the DirectAccess connection process.

The NLS service is normally a highly available website, such as servers in a Network Load Balanced (NLB) cluster or a Windows cluster.

DirectAccess Connection Process

The DirectAccess client is very robust and will try a variety of methods to connect to the corporate network. The connection process is started when the DirectAccess client detects that it is connected to a network—that is, a network transition such as the connection to a LAN, wireless access point, or other connection becomes active.

The DirectAccess client goes through the following connection process when it detects that it is connected to a network:

This entire process is transparent to the user and requires no user interaction. In the event of an interruption in network connectivity, the DirectAccess client will reestablish the connection through this process when it detects network connectivity again.