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.

Leave a comment

19 Comments

  1. Craig

     /  November 2, 2015

    I have just completed adding my first multi-site entry point and neither of my entry points have a /59 IPv6 prefix associated with their IP-HTTPS interfaces (they still have /64 prefixes). Is this an issue?

    Reply
    • You won’t see the /59 assigned to an individual node or interface. The /59 is designated for the entry point as a whole, with /64 subnets from that prefix assigned to each node.

      Reply
      • Craig

         /  November 8, 2015

        Hmm, that is strange as I definitely have a /64 Prefix assigned to both my entry points. I only have one server in each Entry Point and no load balancing so I wonder if that has any bearing.

      • Nope. As soon as you enable multisite, a /59 is designated for the first entry point and each node in that entry point will receive a /64. If you look on the DirectAccess server itself, you’ll only see the /64. To see the /59 prefix designation you’ll have to look in the Remote Access Management console. Under “Configuration” highlight “DirectAccess and VPN”. Then highlight the entry point (not an individual node) and you will see the /59 prefix in the “Entry Point Configuration Summary” window.

  2. Craig

     /  November 9, 2015

    I can’t post screen shots but that’s what I’m doing and it’s definitely a /64 prefix. Everything seems to working though (except Lync but I think I know what’s the matter there).

    Reply
  3. cyaz

     /  February 7, 2017

    Hi Richard,

    I’m seeing a behavior where Windows 7 clients keep on using their DA server’s AD site.

    My DA deployment is load balanced but not multisite, using only iphttps. ClientIPv6Prefix is xxxx:xxxx:xxxx:1000/59, clients are using addresses in xxxx:xxxx:xxxx:1000/64, xxxx:xxxx:xxxx:1001/64… depending on the DA server they are connected to, and InternalIPv6Prefix is xxxx:xxxx:xxxx:1/64.
    I’ve added all of these as subnets, as I wasn’t really sure which was which.

    Have you already seen this?
    Thanks, and great blog by the way!

    Reply
    • You should only have to create an AD subnet for the /59 IPv6 prefix. With that, your Windows 7 clients will then be assigned to the AD site that subnet is assigned to. That should be the same site as the DirectAccess servers, so it sounds like it is working as expected in your environment.

      Reply
      • cyaz

         /  February 9, 2017

        Hi Richard and thanks for your answer 🙂
        I should have been more specific : my DA servers have a single NIC, and they are assigned to the AD site corresponding to their IPv4 subnet.
        Which also means that my DA clients are assigned to the AD site corresponding to the IPv4 subnet of my DA servers, IPv6 subnet seems to be ignored…

      • Ok. That’s expected behavior for Windows 8.x/10 clients. They will always assume the AD site of the DirectAccess server they connected to.

  4. cyaz

     /  February 9, 2017

    Except these are all Windows 7 clients ^^
    But anyway, they will get migrated to Windows 10 eventually so there is not much point spending a lot of time here.
    Thanks 🙂

    Reply
  5. Hi Richard,

    you wrote: Windows 8.x and later clients automatically associate themselves with the site to which the DirectAccess server they are connected to belongs. So far, so good.

    Now we have had to change the AD site for the DirectAccess server for a customer. An nltest / dsgetsite on the DA server also outputs the new AD site. The clients, however, still keep the old site and do not inherit the changed AD site!

    In the associated client GPO I see that the AD sites are given to the DA clients in the form of registry settings (I think under SOFTWARE\Policies\Microsoft\Windows\Tcpip\v6Transition\AdSites\*.*). These parameters are not modified, even if, for example, I make any change in the DA configuration and thus refill the GPOs.

    Do you have a tip on this? Should I just edit the GPO by hand and enter the new site name?

    I think Robin has the same problem here?!: https://social.technet.microsoft.com/Forums/azure/en-US/08e4c806-35f0-4621-b6c8-6cf18ddbe9ba/site-assignment-for-group-policy-for-direct-access-site-with-no-domain-controller?forum=forefrontedgeiag

    Cheers, Karsten…

    Reply
    • I would not edit the GPOs yourself. However, if you haven’t already done so, I would suggest updating the management servers on the DirectAccess server after you make your changes to the DC infrastructure. You can do this in the UI or simply run the Update-DaMgmtServer PowerShell command. Hopefully that fixes the problem. 🙂

      Reply
    • Jeroen Bakker

       /  December 10, 2021

      We ran into the same issue today with a new AD site topology not being reflected on the Direct Access clients.
      After some research the solution is to use powershell command Set-DAEntryPointTableItem with the ADSite parameter:
      https://docs.microsoft.com/en-us/powershell/module/directaccessclientcomponents/set-daentrypointtableitem?view=windowsserver2019-ps

      As far as I can find Richard is correct in his statement that the client AD site assignment follows the AD site assigned to the DA server. Problem is the DA group policy takes the AD site as in use at the moment a new entrypoint is created and sets this sitename in the GPO. If at any future moment the DA server site changes for whatever reason this is not automatically updated in the GPO. This may result in wrong or non-existing sites being assigned to the DA clients.

      Reply
      • This is why it is imperative to update the DirectAccess management server configuration any time changes are made to Active Directory infrastructure. You can do this by running the Update-DaMgmtServer command on a DirectAccess server.

  6. Hi Richard,

    I also had the idea of filling the client GPO with new content, such as an update of the management server.
    Unfortunately, this does not result in the AD site portion being modified in the registry settings.
    So we can say: the client GPO inherits the AD site of the DirectAccess server when it is first created, but is never updated again.

    It’s a shame actually! ;-(

    Greetings and thanks, Karsten …

    Reply
    • That’s intersting. The setting might be buried somewhere else. I’ll dig around and see if I can find something for you. Stay tuned!

      Reply
  7. Hi Richard , awesome post – thanks. Do you have any refererence to official doc from MS since win 10 the client gets the site from the DA server? Trying to find anything official but can only find this blog post 🙂

    Reply
    • I don’t, unfortunately. This is something I learned from discussions I had with some of the DirectAccess developers many years ago. I don’t think I’ve ever seen it formally documented anywhere, though.

      Reply

Leave a Reply

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading