Planning for Multi-site DirectAccess

Applies To: Windows 7, Windows Server 2008 R2

DirectAccess servers can be installed in multiple sites of an organization to increase capacity and provide more efficient routing when accessing site-specific intranet resources. Setting up multi-site DirectAccess requires careful design and planning so that the following goals are met:

• A DirectAccess client can connect to the DirectAccess server of any site and can access the intranet resources in that site.

• A DirectAccess client can be managed by a management server of any site.

• A DirectAccess client can travel to any site and determine that it is connected to the intranet.

The following figure shows an example of DirectAccess deployed in two sites of the Contoso Corporation.

Example of a DirectAccess multi-site deployment

Site 1 is the Contoso Corporation’s main office in the United States, corresponding to the Active Directory Domain Services (AD DS) domain and Domain Name System (DNS) namespace usa.corp.contoso.com. Site 2 is the Contoso Corporation’s main office in Europe, corresponding to the AD DS domain and DNS namespace europe.corp.contoso.com.

DirectAccess Client 1 is a member of the usa.corp.contoso.com domain. When on the Internet, DirectAccess Client 1 connects to the DirectAccess server for the site containing the resources it needs to access. To access a resource in Site 1, the DirectAccess client creates infrastructure and intranet tunnels to DirectAccess Server 1. To access a resource in Site 2, the DirectAccess client creates separate infrastructure and intranet tunnels to DirectAccess Server 2. The following figure shows an example of the infrastructure and intranet tunnels created by DirectAccess Client 1 to reach resources in Site 1 and Site 2.

Example of the tunnels created by DirectAccess Client 1 to access the resources of different sites

DirectAccess Client 1 can be managed by the management servers in Site 1 or Site 2.

The following sections describe the design and planning of multi-site DirectAccess for different elements of DirectAccess and intranet infrastructure.

IPv6 connectivity for multi-site DirectAccess

In a single-site DirectAccess deployment, a DirectAccess server acts as a default Internet Protocol version 6 (IPv6) router for an organization. Default route traffic that is traveling out of the site destined for DirectAccess clients on the Internet must go through the DirectAccess server.

In a multi-site DirectAccess deployment, DirectAccess servers still act as default routers for a site to facilitate traffic to Internet destinations. However, additional routing support must be configured so that IPv6 traffic between computers directly attached to the intranet in different sites does not flow through the DirectAccess servers. Inter-site IPv6 traffic between intranet computers must flow through intranet IPv6 routers if you have native IPv6 connectivity or Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) site border routers if you have ISATAP-based connectivity.

Native IPv6 connectivity

For native IPv6 connectivity, your intranet should support the following:

• Reachability between all IPv6 subnets of your organization

• Default route traffic destined for the Internet for each site flows through the site’s DirectAccess server

ISATAP connectivity

Because most organizations do not have native IPv6 connectivity on their intranets, the DirectAccess Setup Wizard can automatically configure the DirectAccess server as an ISATAP router, deploying ISATAP-based IPv6 connectivity on your intranet. For information about Active Directory Sites and Services configuration for ISATAP-based intranets, see the “Active Directory Sites and Services configuration” section of Design Active Directory for DirectAccess.

With a single-site DirectAccess deployment, the single DirectAccess server acting as the ISATAP router for the site achieves the goals of providing IPv6 reachability throughout the intranet and default route traffic flows through the DirectAccess server. For a multi-site DirectAccess deployment using only ISATAP-based IPv6 connectivity, you must also deploy ISATAP site border routers.

When you deploy DirectAccess servers in multiple sites, by default there is ISATAP-based IPv6 connectivity within each site and the default route traffic flows through the site’s DirectAccess server. Without ISATAP border routers, the inter-site traffic follows the default route path and flows to the DirectAccess server, which can then use 6to4 encapsulation to forward the traffic over the Internet to the DirectAccess server of the destination site. Because there are no connection security rules for inter-site traffic, by default the DirectAccess server can send the traffic as clear text across the Internet. If you deploy ISATAP border routers, ISATAP hosts have additional routes for intranet sites and forward inter-site traffic to the ISATAP border routers.

The ISATAP site border routers have a different role than the DirectAccess server that is acting as a default router for each site. The DirectAccess server configures each ISATAP host within its site with the 64-bit IPv6 prefix of the ISATAP subnet for the site and a default route that points to the DirectAccess server. An ISATAP border router advertises the following routes to ISATAP hosts within its site:

• The 64-bit prefix of the site

  This provides fault tolerance for ISATAP hosts to configure their ISATAP address in case they do not receive the router advertisement from the DirectAccess server.

• The 64-bit prefixes of the other sites that are reachable through the ISATAP border router

  This provides reachability to the other sites.

ISATAP hosts perform router discovery with all ISATAP routers within their sites (the DirectAccess server and the ISATAP border routers), resulting in the routes needed to reach the following:

• All the IPv6 destinations within its own site through the site’s 64-bit prefix route, as received from the DirectAccess server and the ISATAP border routers

• All the IPv6 destinations within the other sites in the organization through site-specific 64-bit prefix routes, as received from the ISATAP border routers

• DirectAccess clients anywhere on the Internet through the default route, as received from the DirectAccess server

If your ISATAP border routers have multiple physical interfaces and your intranet backbone is IPv6-capable, attach an interface of the ISATAP border router to the backbone and configure the appropriate routes to advertise over the ISATAP border router’s ISATAP interface. The following figure shows an example.

Example of connecting ISATAP border routers to an IPv6-capable backbone

If the intranet backbone is not IPv6-capable or you cannot place physical interfaces of the ISATAP border routers on the backbone, you can tunnel inter-site IPv6 traffic between ISATAP border routers using an IPv6-in-Internet Protocol version 4 (IPv4) point-to-point tunnel. This simple router-to-router tunnel allows an ISATAP border router to forward the traffic destined to another site directly to the other site’s ISATAP border router by encapsulating IPv6 packets with an IPv4 header. With an IPv6-in-IPv4 point-to-point tunnel, you can set up the ISATAP border router anywhere within the site. The combination of IPv6-in-IPv4 point-to-point tunnels and routes provides inter-site reachability.

The following figure shows an example of ISATAP border routers within Site 1 and Site 2 that use an IPv6-in-IPv4 point-to-point tunnel to forward inter-site traffic.

Example of an IPv6-in-IPv4 point-to-point tunnel between ISATAP border routers

To provide fault tolerance for inter-site traffic, you can deploy an additional ISATAP border router in each site that has the identical routing configuration as the initial ISATAP border routers, but use their own IPv6-in-IPv4 point-to-point tunnel. The following figure shows an example.

Example of using multiple ISATAP border routers between sites

ISATAP routing can be configured using many modern hardware routers. See the documentation for your router for support and configuration information. A computer running Windows Server 2008 or later can also act as an ISATAP border router.

Active Directory for multi-site DirectAccess

For the configuration of multi-site DirectAccess discussed in this topic, each site is configured for a different AD DS domain with a corresponding DNS suffix. For our example, Site 1 uses the usa.corp.contoso.com AD DS domain and Site 2 uses europe.corp.contoso.com. Other configurations are possible but are beyond the scope of this topic.

For information about Active Directory and DirectAccess, see Design Active Directory for DirectAccess.

DNS for multi-site DirectAccess

For the configuration of multi-site DirectAccess discussed in this topic, each site is configured for a different DNS suffix. For our example, Site 1 uses the usa.corp.contoso.com DNS suffix and Site 2 uses europe.corp.contoso.com. Other configurations are possible but are beyond the scope of this topic.

Intranet DNS records

For a multi-site DirectAccess deployment, you might have to create the following additional DNS records within each site:

• Address (A) or IPv6 address (AAAA) records for the network location server fully qualified domain name (FQDN) with the addresses of the site-specific network location server

• A or AAAA records for the intranet certificate revocation list (CRL) distribution point FQDN with the addresses of the site-specific Web or file servers that host the CRL files

• For each ISATAP site boundary router within the site, an A record for the name ISATAP with the IPv4 address of an ISATAP boundary router interface that is attached to the local site

You can also create multiple A or AAAA records for the network location server and CRL distribution points in all your sites and deploy GSLB within your intranet to return the A or AAAA record for the network location server and CRL distribution point within each site.

Internet DNS records

For a multi-site DirectAccess deployment, you must create A records for the Internet FQDN of each DirectAccess server and the FQDN of each CRL distribution point server. These records allow the DirectAccess client to resolve the address of the DirectAccess server of the site in which it is a domain member for Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS)-based connections and validate the DirectAccess server’s Secure Sockets Layer (SSL) certificate.

For our example, the following A records are needed:

• The name da1.contoso.com and the public IPv4 address of DirectAccess Server 1.

• The name da2.contoso.com and the public IPv4 address of DirectAccess Server 2.

• The name crl.contoso.com and the public IPv4 address of CRL distribution point server.

NRPT

In a multi-site DirectAccess deployment, DirectAccess clients create infrastructure and intranet tunnels to the DirectAccess server that is connected to the site containing the destination of the traffic. To create the infrastructure tunnel to the DirectAccess server for each site and send DNS query traffic for site-specific resources to site-specific DNS servers, DirectAccess clients must be configured with Name Resolution Policy Table (NRPT) namespace rules that include the DNS suffixes of all sites.

For our example, the DirectAccess client Group Policy objects (GPOs) for both Site 1 and Site 2 must be configured with the following namespace rules:

• usa.corp.contoso.com suffix with the IPv6 address of a DNS server in Site 1

• europe.corp.contoso.com suffix with the IPv6 address of a DNS server in Site 2

You can configure the namespace rules for other sites in step 3 of the DirectAccess Setup Wizard or in the Computer Configuration\Policies\Windows Settings\Name Resolution Policy node of the GPO for DirectAccess clients.

PKI for multi-site DirectAccess

To distribute computer certificates to DirectAccess clients and servers with your public key infrastructure (PKI), enabling computer certificate autoenrollment for the domains in all sites containing a DirectAccess server is recommended. You can also use manual enrollment.

Intranet CRL distribution points

DirectAccess clients use the intranet CRL distribution point to perform certificate revocation checking and validate the SSL certificate of the network location server.

The recommended configurations of intranet CRL distributions points are the following:

• A single CRL path (a uniform resource locator [URL] or universal naming convention [UNC]) with a single, highly-available, organization-wide intranet CRL distribution point server

  This is the easiest to deploy, but requires certificate revocation checking traffic to cross site boundaries. Intranet DNS records resolve the FQDN in the CRL path to the CRL distribution point server.

  For our example, the certification authority (CA) publishes its CRL files to a hosting server named crl.corp.contoso.com in Site 1. The issued certificates contain the CRL path https://crl.corp.contoso.com and all of the DirectAccess clients in both sites obtain the CRL files from this server for certificate revocation checking. An intranet DNS record resolves crl.corp.contoso.com to the IP address of the CRL distribution point server.

• A single CRL path with per-site, highly-available, intranet CRL distribution point servers

  In this configuration, the CA publishes its CRL files to a specific server and the files are automatically replicated or shared to CRL distribution point servers within each site. DNS records within each site resolve the FQDN in the path to per-site server IP addresses.

  For our example, the Contoso CA publishes its CRL files to a Web server in Site 1, which automatically replicate to a Web server in Site 2. The issued certificates contain the CRL path https://crl.corp.contoso.com. In Site 1, a DNS record resolves crl.corp.contoso.com to the IP addresses of Web servers in Site 1. In Site 2, a DNS record resolves crl.corp.contoso.com to the IP addresses of Web servers in Site 2. DirectAccess clients and servers obtain CRL files from the CRL distribution point servers within their site.

• Per-site CRL path with per-site, highly-available, intranet CRL distribution point servers

  This configuration requires a CA for each site with a site-specific CRL path and CRL distribution point server. DNS records within each site resolve the FQDN in the path to a per-site server IP address. A DirectAccess client on the intranet that is not connected to its own site must cross site boundaries to obtain CRL files for its own CA.

  For our example, a CA in Site 1 publishes its CRL files to Web servers in Site 1. The certificates issued by the CA in Site 1 contain the CRL path https://crl_site1.corp.contoso.com. In Site 1, a DNS record resolves crl_site1.corp.contoso.com to the IP addresses of the Web servers in Site 1. The CA in Site 2 publishes its CRL files to Web servers in Site 2. The certificates issued by the CA in Site 2 contain the CRL path https://crl_site2.corp.contoso.com. In Site 2, a DNS record resolves crl_site2.corp.contoso.com to the IP addresses of the Web servers in Site 2.

Certificate requirements for network location certificates

For the network location server SSL certificate with a single network location URL and organization-wide CRL paths:

• In the Subject field, the FQDN of the single network location URL

• In the Enhanced Key Usage field, the Server Authentication object identifier (OID)

• In the CRL Distribution Points field, the organization-wide CRL distribution points

For the network location server SSL certificate with a single network location URL and per-site CRL paths:

• In the Subject field, the FQDN of the single network location URL

• In the Enhanced Key Usage field, the Server Authentication OID

• In the CRL Distribution Points field, the site-specific intranet CRL distribution points

Internet CRL distribution point

DirectAccess clients use the Internet CRL distribution point to perform certificate revocation checking and validate the SSL certificate of the DirectAccess server when using IP-HTTPS-based connections. The combinations of Internet CRL distributions points depend on the CAs that issue the SSL certificates to the DirectAccess servers:

• A single, highly-available, organization-wide CA and highly-available Internet CRL distribution point servers

  A single CA publishes the CRL files to Internet-facing CRL distribution point servers and Internet DNS records map the FQDN in the CRL path to Internet-accessible IP addresses.

  For our example, a single CA issues SSL certificates to both DirectAccess servers and the CRL files are hosted by highly-available Internet-facing Web servers using the CRL path crl.contoso.com.

• Per-site CAs and multiple Internet CRL distribution point servers

  Each CA publishes its CRL files to site specific Internet-facing Web servers and Internet DNS records map the FQDN in the CRL paths to Internet-accessible IP addresses.

  For our example, the CA in Site 1 issues an SSL certificate to DirectAccess Server 1 and the CRL files are hosted by Internet-facing Web servers in Site 1 using the FQDN crl_site1.contoso.com. Internet DNS records resolve crl_site1.contoso.com to the IP addresses of the Internet-facing Web servers for Site 1. The CA in Site 2 issues an SSL certificate to DirectAccess Server 2 and the CRL files are hosted by Internet-facing Web servers in Site 2 using the FQDN crl_site2.contoso.com. Internet DNS records resolve crl_site2.contoso.com to the IP addresses of the Internet-facing Web servers for Site 2.

Certificate requirements for IP-HTTPS certificates

For a single CA that issues SSL certificates that are installed on DirectAccess servers for IP-HTTPS connections:

• In the Subject field, either an IPv4 address of the Internet interface of the site-specific DirectAccess server or the FQDN (recommended) of the IP-Secure Hypertext Transfer Protocol (HTTPS) URL

• In the Enhanced Key Usage field, the Server Authentication OID

• In the CRL Distribution Points field, the organization-wide CRL distribution points on the Internet

For per-site CAs that issue SSL certificates that are installed on DirectAccess servers for IP-HTTPS connections:

• In the Subject field, either an IPv4 address of the Internet interface of the site-specific DirectAccess server or the FQDN (recommended) of the IP-HTTPS URL

• In the Enhanced Key Usage field, the Server Authentication OID

• In the CRL Distribution Points field, the site-specific CRL distribution points on the Internet

Network location servers for multi-site DirectAccess

The following are combinations of deploying network location servers for multi-site DirectAccess:

• A single organization-wide network location URL with highly-available Web servers located in a single site

  This is the easiest to deploy, but network location detection traffic for DirectAccess clients that are not connected to the site containing the Web servers must cross site boundaries. Intranet DNS records resolve the FQDN in the network location URL to the Web servers.

  For our example, Web servers in Site 1 host the URL https://nls.corp.contoso.com and all the DirectAccess clients in Site 1 and Site 2 attempt to access it during network location detection.

• A single, organization-wide network location URL with per-site, highly-available Web servers

  All of the DirectAccess clients are configured with the same network location URL but network location detection traffic stays within the site to which the DirectAccess client is attached. DNS records within each site resolve the FQDN in the network location URL to the IP addresses of the Web servers in the site. This is the recommended configuration.

  For our example, DNS records in Site 1 resolve the name nls.corp.contoso.com to Web servers in Site 1 that host the https://nls.corp.contoso.com URL. DNS records in Site 2 resolve the name nls.corp.contoso.com to Web servers in Site 2 that host the https://nls.corp.contoso.com URL.

Force tunneling for multi-site DirectAccess

DirectAccess clients configured for force tunneling send all of their Internet traffic through their DirectAccess server. Force tunneling configuration consists of enabling the Route all traffic through the internal network Group Policy setting and adding an NRPT rule to send DNS queries for all names to either a dual protocol (IPv4 and IPv6) proxy server or an IPv6/IPv4 translator and IPv6/IPv4 DNS gateway in front of your IPv4-based proxy server. Because both of these settings are stored in the Group Policy objects for DirectAccess clients, you can define force tunneling on a per-site basis.

For our example, you can configure force tunneling behavior for the DirectAccess clients of Site 1 but not for the DirectAccess clients of Site 2. Additionally, you can configure all of your DirectAccess clients in multiple sites to use a single, common dual protocol proxy server or IPv6/IPv4 translator and IPv6/IPv4 DNS gateway that are in a specific site. For example, you can configure force tunneling for both Site 1 and Site 2, but DirectAccess clients from both sites use a dual protocol proxy server or IPv6/IPv4 translator and IPv6/IPv4 DNS gateway that are located in Site 1.

Connection security rules for multi-site DirectAccess

DirectAccess clients use connection security rules to determine when to create the tunnels needed to access intranet resources, for management traffic, end-to-end protection, and for correct intranet behavior. In a single-site DirectAccess deployment, the default set of connection security rules can consist of the following, based on your selections in the DirectAccess Setup Wizard:

• The intranet tunnel rule

  Used by the DirectAccess client to access intranet resources. The intranet tunnel rule has the default name DirectAccess Policy-ClientToCorp.

• The network location exemption rule

  Used by the DirectAccess client to exempt Internet Protocol security (IPsec) protection when the network location server is only available over IPv6. The network location server exemption rule has the default name DirectAccess Policy-clientToNlaExempt.

• The management tunnel rule

  If you specified management servers in Step 3 of the DirectAccess Setup Wizard, this rule is used to allow incoming connections from management servers on the intranet. The management tunnel rule for a DirectAccess client GPO of a site has the default name DirectAccess Policy-ClientToMgmt.

• Selected server transport rule

  If you specified selected servers in Step 4 of the DirectAccess Setup Wizard, this rule is used by DirectAccess clients to protect traffic end-to-end between the DirectAccess client and the intranet resource. The selected server transport rule for a DirectAccess client GPO of a site has the default name DirectAccess Policy-clientToAppServer.

To ensure that every DirectAccess client from any home site operates properly from the Internet and when connected to any site, DirectAccess clients must be configured with the connection security rules for the DirectAccess client GPOs of all sites. Therefore, for the DirectAccess client GPO of each site, you must add the following connection security rules:

• The infrastructure tunnel rules for all other sites

  For each site, you must create rules with different names that have the settings of the DirectAccess Policy-ClientToDnsDc connection security rules of the other sites.

  For our example, you create a connection security rule named DirectAccess Policy-ClientToDnsDc_Site2 in the DirectAccess client GPO of Site 1 with the settings of the DirectAccess Policy-ClientToDnsDc connection security rule in the DirectAccess client GPO of Site 2. You also create a connection security rule named DirectAccess Policy-ClientToDnsDc_Site1 in the DirectAccess client GPO of Site 2 with the settings of the DirectAccess Policy-ClientToDnsDc connection security rule in the DirectAccess client GPO of Site 1.

• The intranet tunnel rules for all other sites

  For each site, you must create rules with different names that have the settings of the DirectAccess Policy-ClientToCorp connection security rules of the other sites.

  For our example, you create a connection security rule named DirectAccess Policy-ClientToCorp_Site2 in the DirectAccess client GPO of Site 1 with the settings of the DirectAccess Policy-ClientToCorp connection security rule in the DirectAccess client GPO of Site 2. You also create a connection security rule named DirectAccess Policy-ClientToCorp_Site1 in the DirectAccess client GPO of Site 2 with the settings of the DirectAccess Policy-ClientToCorp connection security rule in the DirectAccess client GPO of Site 1.

• The network location server exemption rules for all other sites

  For each site, you must create rules with different names that have the settings of the DirectAccess Policy-clientToNlaExempt connection security rules of the other sites.

  For our example, you create a connection security rule named DirectAccess Policy-ClientToNlaExempt_Site2 in the DirectAccess client GPO of Site 1 with the settings of the DirectAccess Policy-ClientToNlaExempt connection security rule in the DirectAccess client GPO of Site 2. You also create a connection security rule named DirectAccess Policy-ClientToNlaExempt_Site1 in the DirectAccess client GPO of Site 2 with the settings of the DirectAccess Policy-ClientToNlaExempt connection security rule in the DirectAccess client GPO of Site 1.

• The management tunnel rules for all other sites

  For each site, you must create rules with different names that have the settings of the DirectAccess Policy-ClientToMgmt connection security rules of the other sites.

  For our example, management servers have been specified for both sites. You create a connection security rule named DirectAccess Policy-ClientToMgmt_Site2 in the DirectAccess client GPO of Site 1 with the settings of the DirectAccess Policy-ClientToMgmt connection security rule in the DirectAccess client GPO of Site 2. You also create a connection security rule named DirectAccess Policy-ClientToMgmt_Site1 in the DirectAccess client GPO of Site 2 with the settings of the DirectAccess Policy-ClientToMgmt connection security rule in the DirectAccess client GPO of Site 1.

• The selected server transport rules for all other sites

  For each site, you must create rules with different names that have the settings of the DirectAccess Policy-clientToAppServer connection security rules of the other sites.

  For our example, selected servers have been specified for both sites. You create a connection security rule named DirectAccess Policy-clientToAppServer_Site2 in the DirectAccess client GPO of Site 1 with the settings of the DirectAccess Policy-clientToAppServer connection security rule in the DirectAccess client GPO of Site 2. You also create a connection security rule named DirectAccess Policy-clientToAppServer_Site1 in the DirectAccess client GPO of Site 2 with the settings of the DirectAccess Policy-clientToAppServer connection security rule in the DirectAccess client GPO of Site 1.