Introduction
When deploying Windows Server 2012 R2 DirectAccess I’m often asked which Active Directory (AD) site a client is associated with when it establishes DirectAccess connectivity. The answer depends on the client’s operating system. Windows 8.x and later clients automatically associate themselves with the site to which the DirectAccess server they are connected to belongs. Windows 7 clients lack this capability, and depending on current AD configuration, Windows 7 clients may associate with an incorrect site. This can lead to potential problems such as slow logon times and mapped drive failures. To address this issue it is important to configure IP subnets in AD for DirectAccess clients to eliminate any potential problems. In this article I’ll demonstrate how to create IP subnets in AD and how to identify IPv6 subnets used by DirectAccess clients.
Active Directory IP Subnets
Configuring IP subnets in AD is relatively straightforward. In the Active Directory Sites and Services management console, right-click Subnets and choose New Subnet. Enter the IP subnet prefix and select the AD site where the DirectAccess server for this subnet resides.
IPv6 Subnets for DirectAccess Clients
To configure AD IP subnets for DirectAccess clients, it will be necessary to identify all potential IP subnets that may be in use. IP subnets used by DirectAccess clients depend on the IPv6 transition protocols supported by the DirectAccess configuration. DirectAccess supports 6to4, Teredo, and IP-HTTPS for client to server communication, and the Intrasite Automatic Tunnel Addressing Protocol (ISATAP) for manage-out connectivity. Any or all of these protocols may be used for a particular DirectAccess configuration.
- 6to4 – Supported if the DirectAccess server is edge-facing with a public IPv4 address assigned to its external network interface.
- Teredo – Supported if the DirectAccess server is edge-facing with two consecutive public IPv4 addresses assigned to its external network interface.
- IP-HTTPS – Supported in all deployment scenarios, and is used exclusively if the DirectAccess server is located behind a NAT device in a perimeter or DMZ network.
- ISATAP – Optionally used when manage out is enabled and configured.
IP subnets should be configured in AD for all IPv6 transition protocols supported for the DirectAccess deployment.
Identify the 6to4 IPv6 Subnet
Note: Information for the 6to4 protocol is provided here for completeness. However, it is generally recommended that 6to4 be disabled for DirectAccess deployments, making this configuration unnecessary. More information about disabling 6to4 can be found here.
The 6to4 IPv6 transition protocol is only supported when the DirectAccess server is edge-facing with a public IPv4 address assigned to its external network interface. 6to4 IPv6 addresses are assigned using the 2002::/16 prefix. For single site DirectAccess deployments, an administrator should create an IP subnet in AD using this prefix and assign it to the AD site where the DirectAccess server resides. If public IPv4 addressing is used internally and the 6to4 transition protocol has not been disabled, it is essential that more specific IP subnets for internal 6to4 clients also be configured.
6to4 and DirectAccess Multisite Challenges
The 6to4 IPv6 transition protocol presents a challenge for multisite DirectAccess deployments. When a client creates a 6to4 IPv6 address, it appends the 2002::/16 prefix with its public IPv4 address represented in hexadecimal using the form WWXX:YYZZ::WWXX:YYZZ. For example, if the DirectAccess client’s public IPv4 address is 198.51.100.83, its 6to4 address would be 2002:c633:6453::c633:6453. Since this IPv6 address is created using only the client’s IPv4 address, there is no way to associate the client to a specific entry point. This is one of the reasons why 6to4 is not recommended for use in DirectAccess deployments. If you must support the 6to4 IPv6 transition protocol in a multisite configuration, assign the 2002::/16 IP subnet to the most centrally located AD site.
Identify the Teredo IPv6 Subnet
The Teredo IPv6 transition protocol is only supported when the DirectAccess server is edge facing with two consecutive public IPv4 addresses assigned to its external network interface. Teredo IPv6 addresses begin with 2001: followed by the primary public IPv4 address (represented in hexadecimal) of the DirectAccess server. For example, if the DirectAccess server’s primary public IPv4 address is 203.0.113.240, the DirectAccess client will be assigned a Teredo IPv6 address using the 2001:cb00:71f0::/48 prefix. An administrator should create an IP subnet in AD using this prefix and assign it to the AD site where the DirectAccess server resides. For multisite deployments, repeat these steps for each DirectAccess entry point.
Identify the IP-HTTPS IPv6 Subnet
The IP-HTTPS IPv6 transition protocol is supported in all DirectAccess configurations and its IPv6 subnet should always be assigned to an AD site. The IP-HTTPS IPv6 prefix assignment differs between single site and multisite deployments.
Single Site Deployment
For single site deployments, a /64 IPv6 prefix is assigned for DirectAccess clients. To identify this subnet, run the Get-RemoteAccess PowerShell command on the DirectAccess server and locate the value of ClientIPv6Prefix
Multisite Deployment
For multisite deployments, a unique /64 IPv6 subnet is assigned to single node entry points. If load balancing is enabled, a /59 IPv6 subnet is assigned to the entry point, and each server within the entry point is assigned a /64 prefix for DirectAccess clients. To identify the IPv6 prefixes for each entry point, highlight DirectAccess and VPN below the Configuration node in the Remote Access Management console, and then select the DirectAccess entry point.
For edge facing deployments with a public IPv4 address assigned to the external network interface, the IPv6 prefix assigned to DirectAccess clients is from the 2002::/16 globally unique address (GUA) range. If the DirectAccess server is configured using a private IPv4 address with a single network interface or with two network interfaces behind a NAT, the IPv6 prefix assigned to DirectAccess clients will be from the fd00::/8 unique local address (ULA) range. An administrator should create an IP subnet in AD using this prefix and assign it to the AD site where the DirectAccess server resides.
Note: Uninstalling and reinstalling DirectAccess will result in a new IP-HTTPS network ID being created. If these changes are made, be sure to update AD IP subnets accordingly.
Identify the ISATAP IPv6 Subnet
Although this article focuses primarily on the IPv6 subnets used by remote DirectAccess clients, it is also important not to overlook AD IP subnet configuration for internal clients if ISATAP is configured for manage out. IP subnets used by ISATAP clients vary depending on the network configuration of the DirectAccess server.
Edge Deployment
For edge deployments, ISATAP addresses are assigned from the 2002::/16 GUA range. This is appended with the public IPv4 address of the DirectAccess server in hexadecimal using the form WWXX:YYZZ:1:0:5efe and the IPv4 address of the ISTAP client in familiar dotted-decimal notation. For example, if the DirectAccess server’s primary public IPv4 address is 203.0.113.240 and the client’s IP address is 172.16.1.77, the DirectAccess client will be assigned the ISATAP address 2002:cb00:71f0:1:0:5efe:172.16.1.77. The subnet to be created by the administrator in AD will then be 2002:cb00:71f0:1:0:5efe::/96 plus the IPv4 network prefix. For example, if the client’s IP address uses a /24 prefix, the AD IP subnet would be configured using 2002:cb00:71f0:1:0:5efe:172.16.1.0/120. This IP subnet should be assigned to the same site where the corresponding IPv4 subnet is assigned.
Perimeter/DMZ Deployment
For perimeter/DMZ deployments, ISATAP addresses are assigned randomly from the fd00::/8 ULA range and begin with fdXX:XXXX:XXXX:1:0:5efe followed by the IPv4 address of the ISTAP client in dotted-decimal notation. For example, if the DirectAccess client’s IP address is 172.16.1.77, its ISATAP address might look like fdca:3ce5:b0a:1:0:5efe:172.16.1.77. The subnet to be created by the administrator in AD will then be fdca:3ce5:b0a:1:0:5efe::/96 plus the IPv4 network prefix. If the clients’ IP address uses a /24 prefix, the AD IP subnet would be configured using fdca:3ce5:b0a:1:0:5efe:172.16.1.0/120. This IP subnet should be assigned to the same site where the corresponding IPv4 subnet is assigned.
Summary
The configuration of Active Directory IP subnets for DirectAccess clients is an often overlooked aspect of DirectAccess deployments. Proper IP subnet mapping to AD sites is critical, especially for large enterprise deployments with complex networks spanning multiple physical locations. It ensures that Windows 7 DirectAccess clients communicate with the closest AD domain controller when they establish a DirectAccess connection, which can eliminate potential issues. In addition, it is recommended to disable 6to4 for DirectAccess clients to avoid the pitfalls that come with the use of this IPv6 transition protocol. Also, don’t forget to configure IP subnets for any internal clients that use ISATAP for manage out.
From a client perspective, DirectAccess is an IPv6 only solution. The client communicates with the DirectAccess server and intranet resources using IPv6 exclusively. To enable communication between DirectAccess clients and IPv4 only resources on the internal network, the DirectAccess servers uses two important protocol translators – DNS64 and NAT64. Unfortunately DNS64 and NAT64 provide only inbound protocol translation, so another measure is required for communication initiated outbound to connected DirectAccess clients.
As I mentioned earlier, ISATAP is a global setting by default. However, in most environments there will only be a few systems that will require the ability to initiate outbound communication from the internal network to remote DirectAccess clients. Typically these will be helpdesk administrators’ workstations or management systems. Today we are recommending that you 
