DirectAccess and Windows 10 Technical Preview Build 9926

Looking for more information on Windows 10 and DirectAccess? Click here!

Microsoft recently announced the availability of build 9926 of Windows 10 Technical Preview. This new update includes changes to the user interface that make it easier to view DirectAccess connection status and properties. In this latest build, using the Window Key + I keystroke combination now brings up the Settings menu.

DirectAccess and Windows 10 Technical Preview Build 9926

Figure 1 – Settings Window

To view the DirectAccess connection status, click Network & Internet and then click Show available connections.

DirectAccess and Windows 10 Technical Preview Build 9926

Figure 2 – Network & Internet (Show Available Connections)

Here you’ll find status information for all network connections including DirectAccess. Right-clicking the Workplace Connection will allow the user to disconnect their session, if that option is enabled on the DirectAccess server.

DirectAccess and Windows 10 Technical Preview Build 9926

Figure 3 – DirectAccess Connectivity Status Indicator

Selecting the DirectAccess submenu reveals detailed information about DirectAccess connectivity, including current entry point connection and optional entry point selection, if manual entry point selection is enabled on the DirectAccess server.

DirectAccess and Windows 10 Technical Preview Build 9926

Figure 4 – Network & Internet (DirectAccess Advanced Connection Properties)

Active Directory IP Subnets for DirectAccess Clients

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.

Active Directory IP Subnets for DirectAccess Clients

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

Active Directory IP Subnets for DirectAccess Clients

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.

Active Directory IP Subnets for DirectAccess Clients

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.

Forwarding is Disabled on the DirectAccess Teredo Server

Recently while working with a customer to configure Windows Server 2012 R2 DirectAccess I encountered an issue with Teredo failing after enabling multisite. The remote access management console reported the following error:

Teredo: Not working properly
Error: Forwarding is disabled on the Teredo server.

Forwarding is Disabled on the DirectAccess Teredo Server

The resolution is simple enough. Enable forwarding on the Teredo interface! To do this we’ll need to identity the interface index of the Teredo Tunneling Pseudo-Interface and then enable forwarding using netsh.exe. Open an elevated command prompt and issue the following command:

netsh interface ipv6 show interface

Forwarding is Disabled on the DirectAccess Teredo Server

Make a note of the Teredo tunneling interface index and then enable forwarding on this interface by issuing the following command:

netsh interface ipv6 set interface  forwarding=enabled

Forwarding is Disabled on the DirectAccess Teredo Server

DirectAccess Configuration Load Error after Enabling NLB in Hyper-V

When the Windows Server 2012 R2 DirectAccess server is deployed on a virtual machine running in Microsoft Hyper-V, a complete loss of network connectivity immediately after enabling Network Load Balancing (NLB) may occur. In addition, the Remote Access Management console may report the following error .

Configuration Load Error
Settings for <da_hostname> cannot be retrieved.
Domain controller <dc_hostname> cannot be reached for localhost.
Try to reload the configuration.

DirectAccess Configuration Load Error after Enabling NLB in Hyper-V

This issue may be caused by incorrect virtual network adapter settings on the Hyper-V host. To resolve this issue, open the Hyper-V management console, right-click the DirectAccess guest virtual machine and choose Settings. Expand the virtual network adapter and select Advanced Features, then select the option to Enable MAC address spoofing. Repeat these steps for each virtual network adapter assigned to the DirectAccess server virtual machine. Apply the settings and restart the DirectAccess server.

DirectAccess Configuration Load Error after Enabling NLB in Hyper-V

%d bloggers like this: