All posts tagged ISATAP

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.

19 Comments
by Richard M. Hicks on January 26, 2015  •  Permalink
Posted in 6to4, DirectAccess, IP-HTTPS, IPv6, IPv6 Transition, ISATAP, Remote Access, Security, Teredo, Windows 7, Windows 8, Windows 8.1, Windows Server 2012, Windows Server 2012 R2
Tagged , , , , , , , , , , , , ,

Posted by Richard M. Hicks on January 26, 2015

https://directaccess.richardhicks.com/2015/01/26/active-directory-ip-subnets-for-directaccess-clients/

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

Update: Microsoft is no longer supporting DirectAccess in Azure. More details here.

Recently I wrote an article for CloudComputingAdmin.com about how to configure a basic test lab in Microsoft Azure using Windows Server 2012 R2. After I completed the article, I decided to investigate whether DirectAccess could be configured successfully in Azure. To begin, I looked through the list of unsupported roles and, unfortunately, DirectAccess is on the list. However, just because it isn’t supported doesn’t mean it won’t work, so I proceeded to set up a Windows Server 2012 R2 DirectAccess server to see what would happen. Based on my experience, I can tell you that it does indeed work. However, I quickly learned why it is not supported. There are a number of things unique to the Azure hosting environment that prevent DirectAccess from working without interruption. Although these challenges might prevent you from using DirectAccess in a production environment in Azure, it is certainly viable for short-term testing and evaluation of DirectAccess in Windows Server 2012 R2. Be advised that not all DirectAccess deployment scenarios can be configured in Azure. For example, it is not possible to configure DirectAccess in a public-facing edge configuration. In fact, Azure virtual machines can have only a single NIC, which limits the deployment model to NAT/DMZ configuration. In addition, broadcast and multicast traffic are not supported in a conventional way in Azure, preventing load-balanced clusters and manage out functionality using ISATAP from working correctly.

Configuring the DirectAccess Server in Azure

Note: The DirectAccess server must be joined to a domain, so the assumption is that you’ve configured at least one domain controller somewhere. It can be located in Azure itself, or on-premises with site-to-site VPN established between the on-premises network and the Azure virtual network. Guidance for deploying a Windows Server 2012 R2 domain controller in Azure can be found here. Guidance for configuring site-to-site VPN to Azure using Windows Server 2012 R2 can be found here.

To begin, provision a Windows Server 2012 R2 virtual machine in Microsoft Azure, and be sure to assign a static IP address to the VM using PowerShell as described here. Once the VM is provisioned and available, join it to your domain, install your certificates, and then install the DirectAccess-VPN role. When you first open the Remote Access management console you’ll receive the following errors:

The server does not comply with some DirectAccess prerequisites.
Resolve all issues before proceeding with DirectAccess deployment.

Warning : One or more network adapters should be configured with a static
IP address. Obtain a static address and assign it to the adapter.

Error: The client cannot connect to the destination specified in the
request. Verify that the service on the destination is running and is
accepting requests. Consult the logs and documentation for the
WS-Management service running on the destination, most commonly IIS or
WinRM. If the destination is the WinRM service, run the following
command on the destination to analyze and configure the WinRM service:
"winrm quickconfig".

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

As long as you’ve configured the VM with a static IP address in Azure you can disregard the warning about static IP address assignment. Static IP address assignment in Azure works effectively like a dynamic IP address reservation which will not change, and is sufficient for our purposes here. To resolve the second error, open an elevated command prompt and enter the following command:

winrm quickconfig

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

Click on Check prerequisites again and you’ll find that the warning about static IP address assignment still persists, but you can now click Next to proceed with configuring DirectAccess.

http://azure.microsoft.com/blog/2014/05/14/reserved-ip-addresses/

In the Azure management portal, note the Public Virtual IP (VIP) address assigned to the VM. Configure public DNS with the hostname you entered when configuring DirectAccess (which is used by clients to connect to the DirectAccess server) to resolve to this IP address.

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

To configure external access to the VM for DirectAccess clients click Endpoints and click Add. Select the option to Add a standalone endpoint and then select HTTPS and TCP. Accept the defaults of 443 for both the public and private ports.

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

Provisioning DirectAccess Clients

At this point you should now be able to provision DirectAccess clients. If you’ve configured your DirectAccess lab entirely in Azure, you’ll need to use the offline domain join tool to provision clients. Once you’ve successfully provisioned DirectAccess clients, they should be able to establish connectivity through the DirectAccess server.

Azure DirectAccess Issues

Turning off the DirectAccess virtual machine is when the problems begin. Specifically, stopping the virtual machine and deallocating it, which happens when you choose to shut down the VM via the Azure management portal, tends to break things. However, stopping the DirectAccess server from within the virtual machine itself (using Stop-Computer, shutdown.exe, or the GUI) does not cause any problems, and the DirectAccess server can remain shut down (but not deallocated) for an extended period of time without issue.

When you restart a VM that was previously stopped and deallocated, you may find that the Remote Access management console fails to connect, returning the following error message:

Configuration Load Error

A connection cannot be established to server . Check that the server
is available, the Remote Access role is installed, and that you have
permissions to access the server.

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

Running winrm quickconfig again restores access to the management console. You’ll notice, however, that DirectAccess is not functioning in spite of the fact that the management console states it is. You’ll also find that there are a number of services in an unknown state.

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

This happens because the after the VM is restarted after being deallocated, it receives a new virtual NIC. When the system starts, the DirectAccess configuration is not bound to this network interface. To resolve this issue, go to the DirectAccess and VPN Configuration in the management console and click Edit in the Remote Access Server configuration and choose Network Adapters. You’ll see that the adapter connected to the internal or perimeter network is blank. From the drop-down menu, select the network interface and choose Next,Finish, and then apply the configuration once again.

Configuring Windows Server 2012 R2 DirectAccess in Microsoft Azure

Changes to Public DNS

When the DirectAccess server is deallocated, the public IPv4 address assigned to it is released. If the VM is deallocated for an extended period of time, you will not get your originally assigned public IP address again and a new one is assigned upon restart. You’ll need to update your public DNS record to reflect this change of IP address. It is possible to reserve a public IP address using PowerShell. However, it does require that you reserve the public IP address prior to creating the virtual machine. In addition, you’ll need to create the virtual machine using PowerShell to leverage the reserved public address. As of this writing, reserving public IP addresses is not available through the Azure portal GUI. For more information about reserving public IP addresses in Azure, click here.

Summary

Although it is technically possible to configure DirectAccess on Windows Server 2012 R2 hosted in the Microsoft Azure public cloud, it is formally unsupported and there are a number of factors that make its use potentially problematic. It might be possible that future changes could make this better, but for now it does work in some scenarios if you accept the workarounds. Proceed at your own risk!

18 Comments
by Richard M. Hicks on August 19, 2014  •  Permalink
Posted in DirectAccess, ISATAP, Remote Access, Windows Server 2012 R2
Tagged , , , , , , , , ,

Posted by Richard M. Hicks on August 19, 2014

https://directaccess.richardhicks.com/2014/08/19/configuring-windows-server-2012-r2-directaccess-in-microsoft-azure/

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.

24 Comments
by Richard M. Hicks on August 27, 2013  •  Permalink
Posted in 6to4, Important Links, IPv6, ISATAP, Remote Access, Windows 7, Windows 8, Windows 8.1
Tagged , , , , , , , , , ,

Posted by Richard M. Hicks on August 27, 2013

https://directaccess.richardhicks.com/2013/08/27/disabling-unused-ipv6-transition-technologies-for-directaccess-clients/

« Older Posts
Newer Posts »