Top 5 DirectAccess Troubleshooting Tips

Top 5 DirectAccess Troubleshooting TipsDirectAccess is a thing of beauty when everything is working as it should. When it isn’t, troubleshooting can be quite challenging. DirectAccess relies on many Windows platform technologies such as Active Directory for authentication, PKI for certificate management, group policy for settings deployment, IPsec for encryption, and IPv6 for transport. With so many dependencies, locating the source of the problem can be a difficult and daunting task.

I’m frequently called upon to help organizations of all sizes with DirectAccess troubleshooting. While this post is not intended to be a detailed, prescriptive guide for DirectAccess troubleshooting, I did want to share some common troubleshooting tips based on many years of troubleshooting DirectAccess.

Here are my top 5 DirectAccess troubleshooting tips:

  1. Check Prerequisites – Before diving in and collecting network traces and scouring event logs for clues as to why DirectAccess isn’t working, it’s essential to start at the beginning. Often the source of trouble is missing or misconfigured prerequisites. For example, is the DirectAccess client running a supported operating system? Remember, clients must be running Windows 10 Enterprise or Education, Windows 8.x Enterprise, or Windows 7 Enterprise or Ultimate. Also, ensure that the Windows firewall is enabled on DirectAccess servers and clients, that certificates are installed and valid (trusted, correct EKU, etc.), and that the DirectAccess settings GPO has been applied to servers and clients.
  2. Validate External Connectivity – If you are following implementation and security best practices for DirectAccess, the DirectAccess server will be in a perimeter/DMZ network behind an edge firewall. The firewall must be configured to allow inbound TCP port 443 only. If the firewall is also performing Network Address Translation (NAT), the NAT rule must be configured to forward traffic to the DirectAccess server’s dedicated or virtual IP address (VIP), or the VIP of the load balancer. Watch for routing issues when using load balancers too. It’s a good idea to confirm external connectivity using the Test-NetConnection PowerShell command. Even better, use the open source tool Nmap for more thorough testing.
  3. Remove Third Party Software – I can’t tell you how many times I’ve resolved DirectAccess connectivity issues by removing (not just disabling!) third party software on the client and/or server. It’s not uncommon for third-party security software to interfere with IPsec and/or IPv6 communication, both of which are vital to DirectAccess. If your DirectAccess troubleshooting efforts reveal no underlying issues with prerequisites or external connectivity, I’d suggest removing (at least temporarily) any third-party software and testing again.
  4. Isolate Environmental Issues – Occasionally other settings applied manually or via Active Directory group policy will interfere with DirectAccess. Examples include IPv6 being disabled in the registry, IPv6 transition technologies required to support DirectAccess are turned off, essential firewall rules for DirectAccess are disabled, or manipulating local security settings such as Access this computer from the network. To assist with troubleshooting it might be necessary to temporarily place DirectAccess clients and servers in their own dedicated Organizational Units (OUs) and block inheritance to isolate the configuration as much as possible. In addition, if DirectAccess clients are servers are provisioned using images or templates, testing with a clean build straight from the installation source (ISO or DVD) can be helpful.
  5. Check for Unsupported Configurations – If DirectAccess isn’t working, it might be possible the configuration you are trying to use is not supported. Examples including strong user authentication with OTP when force tunneling is enabled, provisioning Windows 7 clients when using Kerberos Proxy authentication, or provisioning Windows 10 clients when Network Access Protection (NAP) integration is enabled. These configurations won’t work and are formally documented here.

This is by no means a comprehensive or exhaustive troubleshooting guide. For more information and additional DirectAccess troubleshooting guidance I would encourage you to purchase my book Implementing DirectAccess with Windows Server 2016, which has an entire chapter devoted just to troubleshooting. In addition, watch my DirectAccess video training courses on Pluralsight for details and information about DirectAccess installation, configuration, management, support, and troubleshooting. And if you’re still struggling to resolve a DirectAccess problem, use the form at the bottom of this page to contact me to inquire about additional troubleshooting help.

Additional Resources

Microsoft Windows DirectAccess Client Troubleshooting Tool
DirectAccess and Windows 10 Professional
DirectAccess Troubleshooting with Nmap
DirectAccess Unsupported Configurations
Planning and Implementing DirectAccess with Windows Server 2016 Video Training Course on Pluralsight
Implementing DirectAccess with Windows Server 2016 Book

Need assistance with DirectAccess troubleshooting? Complete the form below and I’ll get in touch with you.

Planning and Implementing DirectAccess with Windows Server 2016 Video Training Course on Pluralsight

Planning and Implementing DirectAccess with Windows Server 2016I’m excited to announce my latest video training course, Planning and Implementing DirectAccess with Windows Server 2016, is now available on Pluralsight! In this course, I’ll provide a high-level overview of DirectAccess, compare it with VPN, and outline supporting infrastructure requirements. In addition, you’ll learn how to choose the best network topology for a DirectAccess deployment, how to prepare Active Directory and Public Key Infrastructure (PKI) for DirectAccess, and how to install and configure DirectAccess in Windows Server 2016 using the latest implementation and security best practices. You’ll also learn how to provision Windows 10 clients and understand the unique requirements for supporting Windows 7.

The course includes the following training modules:

Overview of DirectAccess
Planning for DirectAccess
Configuring DirectAccess with the Getting Started Wizard
Configuring DirectAccess with the Remote Access Setup Wizard
Provisioning DirectAccess Clients
Supporting Windows 7 Clients

Throughout the course, I share valuable knowledge and insight gained from more than 5 years of experience deploying DirectAccess for some of the largest organizations in the world. Pluralsight offers a free trial subscription if you don’t already have one, so watch my DirectAccess video training course today!

Additional Resources

Planning and Implementing DirectAccess with Windows Server 2016 on Pluralsight
Implementing DirectAccess with Windows Server 2016

DirectAccess IPv6 Support for WorkSite and iManage Work

DirectAccess IPv6 Support for WorkSite and iManage WorkiManage Work (formerly WorkSite) is a popular document management system commonly used in the legal, accounting, and financial services industries. Historically, there have been issues getting WorkSite to function over DirectAccess, because WorkSite used IPv4 addresses and DirectAccess clients use IPv6. When a DirectAccess client is outside of the office, it communicates with the DirectAccess server using IPv6 exclusively, so applications that make calls directly to IPv4 addresses won’t work.

One way DirectAccess administrators could make WorkSite function was to use portproxy to create v4tov6 address and port mappings on the client. However, this method is error prone, difficult to troubleshoot and support, and doesn’t scale effectively.

The good news is that beginning with release 9, the iManage Work client application has been upgraded to support IPv6. However, it is not enabled by default. To enable IPv6 support for iManage Work, add the following registry key on the client side (not the server!). No other changes are required.

HKLM\Software\Wow6432Node\Interwoven\WorkSite\Server Common\

Type: REG_SZ
String: IP Address Family
Value: IPv6

DirectAccess IPv6 Support for WorkSite and iManage Work

You can also use the following PowerShell command to add this registry entry.

New-Item -Path “HKLM:\Software\Wow6432Node\Interwoven\WorkSite\Server Common\” -Force
New-ItemProperty -Path “HKLM:\Software\Wow6432Node\Interwoven\WorkSite\Server Common\”-Name “IP Address Family” -PropertyType String -Value IPv6 -Force

After validation testing is complete, deploy the registry setting via Active Directory group policy preferences to all DirectAccess clients and iManage Work will function perfectly over DirectAccess!

Additional Resources

Active Directory Group Policy Preferences on Microsoft TechNet

iManage Web Site

Implementing DirectAccess with Windows Server 2016

Windows Clients Do Not Receive DirectAccess Configuration Changes

Windows Clients Do Not Receive DirectAccess Configuration Changes

A scenario can occur in which changes to the DirectAccess configuration made using the Remote Access Management console or at the command line using PowerShell are not reflected on the DirectAccess client, even after receiving the latest group policy updates. The issue occurs for DirectAccess clients that are provisioned with the Offline Domain Join (ODJ, or djoin.exe) tool.

When the ODJ provisioning package is initially created, it does not add the new computer account to the DirectAccess security group. The ODJ-provisioned client receives all DirectAccess configuration settings at the time of provisioning, but it will not receive subsequent changes to the DirectAccess configuration made after it was originally provisioned.

To resolve this issue, be sure to proactively add the DirectAccess client’s computer account to the appropriate DirectAccess security group in Active Directory after provisioning with ODJ using Active Directory Users and Computers (ADUC), the Active Directory Administrative Center (ADAC), or by executing the following PowerShell command:

Add-ADGroupMember -Identity [DirectAccess Client Security Group] -Members [computername]

Once the DirectAccess client has been added to the security group and restarted, it will then receive DirectAccess configuration settings changes going forward.

Configuring Multiple Windows Server 2012 R2 DirectAccess Instances

DirectAccess in Windows Server 2012 R2 supports many different deployment configurations. It can be deployed with a single server, multiple servers in a single location, multiple servers in multiple locations, edge facing, in a perimeter or DMZ network, etc.

Global Settings

There are a number of important DirectAccess settings that are global in scope and apply to all DirectAccess clients, such as certificate authentication, force tunneling, one-time password, and many more. For example, if you configure DirectAccess to use Kerberos Proxy instead of certificates for authentication, Windows 7 clients are not supported. In this scenario it is advantageous to have a second parallel DirectAccess deployment configured specifically for Windows 7 clients. This allows Windows 8 clients to take advantage of the performance gains afforded by Kerberos Proxy, while at the same time providing an avenue of support for Windows 7 clients.

Parallel Deployments

To the surprise of many, it is indeed possible to deploy DirectAccess more than once in an organization. I’ve been helping customers deploy DirectAccess for nearly five years now, and I’ve done this on more than a few occasions. In fact, there are some additional important uses cases that having more than one DirectAccess deployment can address.

Common Use Cases

QA and Testing – Having a separate DirectAccess deployment to perform testing and quality assurance can be quite helpful. Here you can validate configuration changes and verify updates without potential negative impact on the production deployment.

Delegated Administration – DirectAccess provides support for geographic redundancy, allowing administrators to create DirectAccess entry points in many different locations. DirectAccess in Windows Server 2012 R2 lacks support for delegated administration though, and in some cases it may make more sense to have multiple separate deployments as opposed to a single, multisite deployment. For example, many organizations are divided in to different business units internally and may operate autonomously. They may also have different configuration requirements, which can be better addressed using individual DirectAccess implementations.

Migration – If you have currently deployed DirectAccess using Windows Server 2008 R2 with or without Forefront UAG 2010, migrating to Windows Server 2012 R2 can be challenging because a direct, in-place upgrade is not supported. You can, however, deploy DirectAccess using Windows Server 2012 R2 in parallel to your existing deployment and simply migrate users to the new solution by moving the DirectAccess client computer accounts to a new security group assigned to the new deployment.

Major Configuration Changes – This strategy is also useful for scenarios where implementing changes to the DirectAccess configuration would be disruptive for remote users. For example, changing from a single site to a multisite configuration would typically require that all DirectAccess clients be on the LAN or connect remotely out-of-band to receive group policy settings changes after multisite is first configured. In addition, parallel deployments can significantly ease the pain of transitioning to a new root CA if required.

Unique Client Requirements – Having a separate deployment may be required to take advantage of the unique capabilities of each client operating system. For example, Windows 10 clients do not support Microsoft Network Access Protection (NAP) integration. NAP is a global setting in DirectAccess and applies to all clients. If you still require NAP integration and endpoint validation using NAP for Windows 7 and Windows 8.x, another DirectAccess deployment will be required to support Windows 10 clients.

Requirements

To support multiple Windows Server 2012 R2 DirectAccess deployments in the same organization, the following is required:

Unique IP Addresses – It probably goes without saying, but each DirectAccess deployment must have unique internal and external IPv4 addresses.

Distinct Public Hostname – The public hostname used for each deployment must also be unique. Multi-SAN certificates have limited support for DirectAccess IP-HTTPS (public hostname must be the first entry in the list), so consider using a wildcard certificate or obtain certificates individually for each deployment.

Group Policy Objects – You must use unique Active Directory Group Policy Objects (GPOs) to support multiple DirectAccess deployments in a single organization. You have the option to specify a unique GPO when you configure DirectAccess for the first time by clicking the Change link next to GPO Settings on the Remote Access Review screen.

Configuring Multiple Windows Server 2012 R2 DirectAccess Instances

Enter a distinct name for both the client and server GPOs. Click Ok and then click Apply to apply the DirectAccess settings for this deployment.

Configuring Multiple Windows Server 2012 R2 DirectAccess Instances

Windows 7 DirectAccess Connectivity Assistant (DCA) GPOs – If the DirectAccess Connectivity Assistant (DCA) v2.0 has been deployed for Windows 7 clients, separate GPOs containing the DCA client settings for each individual deployment will have to be configured. Each DirectAccess deployment will have unique Dynamic Tunnel Endpoint (DTE) IPv6 addresses which are used by the DCA to confirm corporate network connectivity. The rest of the DCA settings can be the same, if desired.

Supporting Infrastructure

The rest of the supporting infrastructure (AD DS, PKI, NLS, etc.) can be shared between the individual DirectAccess deployments without issue. Once you’ve deployed multiple DirectAccess deployments, make sure that DirectAccess clients DO NOT belong to more than one DirectAccess client security group to prevent connectivity issues.

Migration Process

Moving DirectAccess client computers from the old security group to the new one is all that’s required to migrate clients from one DirectAccess deployment to another. Client machines will need to be restarted to pick up the new security group membership, at which time they will also get the DirectAccess client settings for the new deployment. This works seamlessly when clients are on the internal network. It works well for clients that are outside the network too, for the most part. Because clients must be restarted to get the new settings, it can take some time before all clients finally moved over. To speed up this process it is recommended that DirectAccess client settings GPOs be targeted at a specific OUs created for the migration process. A staging OU is created for clients in the old deployment and a production OU is created for clients to be assigned to the new deployment. DirectAccess client settings GPOs are then targeted at those OUs accordingly. Migrating then only requires moving a DirectAccess client from the old OU to the new one. Since OU assignment does not require a reboot, clients can be migrated much more quickly using this method.

Summary

DirectAccess with Windows Server 2012 R2 supports many different deployment models. For a given DirectAccess deployment model, some settings are global in scope and may not provide the flexibility required by some organizations. To address these challenges, consider a parallel deployment of DirectAccess. This will enable you to take advantage of the unique capabilities of each client operating system, or allow you to meet the often disparate configuration requirements that a single deployment cannot support.

DirectAccess Client and Server Settings GPOs Deleted

Microsoft Windows Server Active DirectoryFor DirectAccess deployments where domain controllers are running Windows Server 2003 or Windows Server 2003 R2 using the File Replication Service (FRS) for replication, DirectAccess client and server settings Group Policy Objects (GPOs) may be deleted. If these GPOs are deleted, DirectAccess connectivity will be disrupted. If the GPOs cannot be recovered via backup, it will be necessary to rebuild the entire DirectAccess deployment from scratch.

Microsoft recently updated their DirectAccess Unsupported Configurations documentation to reflect new guidance for DirectAccess deployments where the FRS is used for the distribution of Active Directory GPOs. DirectAccess is no longer supported in environments where FRS is used for SYSVOL replication.

What this means is that if you plan to deploy DirectAccess, domain controllers must be running Windows Server 2008 or later, and Distributed File System Replication (DFS-R) must be used for replication.

More details can be found here.

DirectAccess NLS Deployment Considerations for Large Enterprises

Introduction

For a DirectAccess deployment, the Network Location Server (NLS) is an infrastructure component that allows DirectAccess clients to determine if they are inside or outside of the corporate network. If the DirectAccess client can successfully connect to the NLS, it is on the internal network and DirectAccess is not used. If the NLS cannot be contacted, the client is outside of the network and will attempt to establish remote corporate network connectivity using DirectAccess.

High Availability

It is recommended that the NLS be made highly available by deploying at least two servers in a load balanced configuration to avoid potential service disruptions for DirectAccess clients inside the corporate network. While this approach is sufficient for networks that are contained in a single physical location, it does present some challenges for large organizations with internal networks that span multiple physical locations.

NLS Challenges

For DirectAccess, only a single NLS URL can be configured per DirectAccess deployment, as shown here.

DirectAccess NLS Deployment Considerations for Large Enterprises

If a WAN outage occurs on an internal network that spans multiple physical locations, internal DirectAccess clients in locations other than where the NLS resides will mistakenly believe they are outside of the corporate network. This can lead to degraded performance and potential loss of connectivity. NLS reliability can still be improved when the internal network spans multiple physical locations by deploying NLS at each physical location and configuring clients to use a local NLS. This will keep traffic off of the WAN and prevent service disruptions in the event of a WAN outage.

Redundant NLS

There are several strategies that can be used to configure internal DirectAccess clients to use a local NLS, including DNS round robin, a network load balancer, or Active Directory Group Policy. Using DNS or a load balancer requires only a single NLS URL. Using Active Directory Group Policy requires a unique NLS URL per physical location.

DNS

The simplest way to enable DirectAccess clients to use a local NLS is to use DNS round robin and take advantage of subnet prioritization. To do this, create an “A” resource record in DNS that resolves to the IPv4 address for each NLS. On the DNS server, open the DNS Manager, right-click the DNS server and choose Properties. Click the Advanced tab and select the options to Enable round robin and Enable netmask ordering.

DirectAccess NLS Deployment Considerations for Large Enterprises

This will ensure that name resolution requests for the NLS FQDN will be returned with the nearest NLS. More information about DNS netmask ordering can be found here.

Load Balancer

A Global Server Load Balancing (GSLB) solution can also be employed to route requests to a local NLS. Examples include F5 Global Traffic Manager (GTM) and Kemp Technologies LoadMaster GEO. Prescriptive guidance for configuring the Kemp LoadMaster for this scenario can be found here.

Group Policy

This method involves creating unique NLS URLs per site and overriding the default DirectAccess client configuration using Active Directory Group Policy. Separate Group Policy Objects (GPOs) are created and linked to Active Directory Sites to assign a local NLS to internal DirectAccess clients. To accomplish this, create a new GPO for each location where NLS will reside. Edit the GPO and navigate to Computer Configuration/Policies/Administrative Templates/Network/Network Connectivity Status Indicator. Double-click Specify domain location determination URL, choose Enabled, and then enter the URL that corresponds to the NLS for that location.

DirectAccess NLS Deployment Considerations for Large Enterprises

In the Remote Access Management Console, edit the Infrastructure Server Setup (Step 3) and add the FQDN for each NLS. Do not specify a DNS server. This effectively creates a Name Resolution Policy Table (NRPT) exemption so the NLS cannot be reached when the DirectAccess client is connected remotely.

DirectAccess NLS Deployment Considerations for Large Enterprises

In the Group Policy Management Console right-click on Sites and choose Show Sites.

DirectAccess NLS Deployment Considerations for Large Enterprises

Select each Active Directory site where NLS will reside.

DirectAccess NLS Deployment Considerations for Large Enterprises

Link the GPOs for each NLS to the corresponding site, then right-click the linked GPO and choose Enforced.

DirectAccess NLS Deployment Considerations for Large Enterprises

Note: Do not install the NLS on a domain controller! By design, the NLS is not reachable remotely by DirectAccess clients. This can lead to potential authentication issues and may prevent DirectAccess clients from connecting successfully.

Client Testing

To confirm that a client computer has been configured to use a local NLS, verify the currently associated Active Directory site by issuing the following command on the DirectAccess client computer:

nltest /dsgetsite

Next, confirm the setting of the NLS by issuing the following command:

Get-NCSIPolicyConfiguration

As a reference, here are examples from two DirectAccess clients in two different internal physical locations:

DirectAccess NLS Deployment Considerations for Large Enterprises

DirectAccess NLS Deployment Considerations for Large Enterprises

Summary

The limitation of a single Network Location Server (NLS) URL for a DirectAccess deployment presents some challenges for DirectAccess architects seeking to eliminate single points of failure in their design. Using the techniques described in this article, administrators can ensure that DirectAccess clients will always connect to a local NLS, eliminating potential failure points and improving the overall reliability of the solution.

Additional Resources

DirectAccess Network Location Server (NLS) Guidance

Configure KEMP LoadMaster Load Balancer for DirectAccess Network Location Server (NLS)

Configure Citrix NetScaler for DirectAccess Network Location Server (NLS)

Configure F5 BIG-IP for DirectAccess Network Location Server (NLS) 

Disable 6to4 IPv6 Transition Protocol for DirectAccess Clients

Introduction

DirectAccess client to server connections are established exclusively over IPv6. To allow for this communication to take place over the public IPv4 Internet, DirectAccess uses IPv6 transition protocols – 6to4, Teredo, and IP-HTTPS – to tunnel IPv6 communication over IPv4. 6to4 is supported when the DirectAccess server is edge facing with a public IPv4 address assigned to its external network interface. Two consecutive public IPv4 addresses are required to support Teredo. IP-HTTPS is used in all scenarios, and exclusively when the DirectAccess server is located in a perimeter or DMZ network behind a NAT device.

6to4 and Teredo Advantages

Not all IPv6 transition protocols are created equal. For Windows 7 clients, 6to4 and Teredo provide significant performance advantages when compared to IP-HTTPS (Windows 8.x clients can use null encryption for IP-HTTPS, which eliminates this performance advantage). 6to4 and Teredo offer nearly identical performance, but 6to4 suffers from some unique challenges and should be disabled by default for all DirectAccess deployments.

Note: IP-HTTPS null encryption is disabled for all clients when client-based remote access VPN or one-time password (OTP) authentication is configured on the DirectAccess server, which can impact performance for Windows 8.x clients using IP-HTTPS.

Unreliable Fallback

The 6to4 IPv6 transition protocol is used when a DirectAccess client has a public IPv4 address assigned to its network interface. 6to4 uses IP protocol 41 for transport, and does not work when the client is behind a NAT. If outbound IP protocol 41 is blocked (a common scenario) then the client should fallback to Teredo or IP-HTTPS. In my experience this doesn’t always happen. In fact, the protocol fallback fails with enough regularity that it is the primary reason I recommend disabling it by default.

Active Directory IP Subnet Assignment

6to4 is also problematic when it comes to configuring Active Directory IP subnets for clients in a multisite DirectAccess deployment. 6to4 addresses begin with the 2002::/16 prefix followed by the IPv4 address of the client 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. The administrator is left with assigning the 2002::/16 prefix to the most centrally located AD site. This will undoubtedly result in some DirectAccess clients using domain controllers that are not ideal, which will ultimately lead to slow log on times and mapped drive failures.

Summary

In some deployment scenarios, 6to4 and Teredo offer performance advantages when compared to IP-HTTPS. Performance is identical for both 6to4 and Teredo, and considering the challenges that 6to4 poses, it should be disabled by default for DirectAccess deployments. This eliminates the possibility of associated connectivity issues, while still allowing DirectAccess clients to use the Teredo IPv6 transition protocol and not incur any performance penalty. Details about disabling IPv6 transition protocols can be found here.

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.

Disabling Unused IPv6 Transition Technologies for DirectAccess Clients

From a client perspective, DirectAccess is an IPv6-only solution and requires IPv6 connectivity end to end. To enable the solution to work on IPv4-only networks, DirectAccess makes use of one of several IPv6 transition technologies – 6to4, Teredo, or IP-HTTPS. By leveraging these IPv6 transition technologies, a DirectAccess client can communicate with the DirectAccess server when they are both connected to the public IPv4 Internet, which is the most common deployment scenario today.

The first two IPv6 transition technologies, 6to4 and Teredo, both require that the DirectAccess server be directly connected to the public Internet. Beginning with Windows Server 2012, placing the DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is now supported. However, in this deployment model only the IP-HTTPS IPv6 transition protocol can be utilized. In this scenario, it is recommended to disable the unused IPv6 transition protocols to prevent potential connectivity issues. You can disable them on a per-host basis using PowerShell, which is fine for individual client testing purposes, or globally using Active Directory Group Policy Objects (GPOs), which is recommend for enterprise-wide production deployment.

To disable unused IPv6 transition protocols on a per-host basis on Windows 8 clients using PowerShell, open an elevated PowerShell prompt and execute the following commands:

Set-Net6to4Configuration –State disabled
Set-NetTeredoConfiguration –Type disabled
Set-NetIsatapConfiguration –State disabled

To disable unused IPv6 transition protocols on a per-host basis on Windows 7 client using netsh, open an elevated command prompt and execute the following commands:

netsh interface 6to4 set state disabled
netsh interface teredo set state disabled
netsh interface isatap set state disabled

To disable unused IPv6 transition protocols using Active Directory GPO, open the Group Policy Management Console (GPMC) and create a new GPO. Edit the GPO by navigating to Computer Configuration / Policies / Administrative Templates / Network / TCP/IP Settings / IPv6 Transition. Double-click Set 6to4 State and enable the policy, then select Disabled State from the list of states. Repeat these steps for Teredo and ISATAP.

Disable DirectAccess IPv6 Transition Protocol using GPO

Change the security filtering for the GPO and specify the security group for your DirectAccess clients. Once complete, link the new GPO to the domain.

Disable DirectAccess IPv6 Transition Protocol using GPO

As a reminder, the steps above are for disabling unused IPv6 transition protocols in a deployment scenario where the DirectAccess server is running Windows Server 2012/R2 and is deployed behind a NAT device. If your DirectAccess server is connected directly to the public Internet, disabling these IPv6 transition protocols is not required.

%d bloggers like this: