A Windows 7 or Windows 8.x/10 client may fail to establish a DirectAccess connection using the IP-HTTPS IPv6transition technology. When troubleshooting this issue, running ipconfig.exe show that the media state for the tunnel adapter iphttpsinterface is Media disconnected.
Running the Get-NetIPHttpsState PowerShell command on Windows 8.x/10 clients or the netsh interface httpstunnel show interface command on Windows 7 clients returns an error code of 0x800b0109 with an interface status Failed to connect to the IPHTTPS server; waiting to reconnect.
Error code 0x800b0109 translates to CERT_E_UNTRUSTEDROOT, indicating the client was unable to establish an IP-HTTPS connection because the certificate presented during the SSL handshake was issued by a certification authority that was not trusted. This commonly occurs when the DirectAccess server is configured with an SSL certificate issued by the internal PKI and DirectAccess clients are provisioned using offline domain joinwithout using the /rootcacerts switch. This can also happen if DirectAccess is configured to use a self-signed certificate for IP-HTTPS, and the certificate is either renewed or DirectAccess is uninstalled and reinstalled.
To resolve IP-HTTPS error code 0x800b0109, obtain the root certificate for the certificate authority that issued the SSL certificate used for IP-HTTPS and import it in to the DirectAccess client’s Trusted Root Certification Authorities local computer certificate store. Once complete, restart the IP helper service to reinitiate an IP-HTTPS connection.
Recently I’ve written about the security challenges with DirectAccess, specifically around the use of the IP-HTTPS IPv6 transition technology. In its default configuration, the DirectAccess server does not authenticate the client when an IP-HTTPS transition tunnel is established. This opens up the possibility of an unauthorized user launching Denial-of-Service (DoS) attacks and potentially performing network reconnaissance using ICMPv6. More details on this can be found here.
Mitigation
The best way to mitigate these security risks is to implement an Application Delivery Controller (ADC) such as the F5 BIG-IP Local Traffic Manager or the Citrix NetScaler. I’ve documented how to configure those platforms here and here.
No ADC?
For those organizations that do not have a capable ADC deployed, it is possible to configure the IP-HTTPS listener on the Windows Server 2012 R2 server itself to perform preauthentication.
Important Note: Making the following changes on the DirectAccess server is not formally supported. Also, this change is incompatible with one-time passwords (OTP) and should not be performed if strong user authentication is enabled. In addition, null cipher suites will be disabled, resulting in reduced scalability and degraded performance for Windows 8.x and Windows 10 clients. Making this change should only be done if a suitable ADC is not available.
Configure IP-HTTPS Preauthentication
To configure the DirectAccess server to perform preauthentication for IP-HTTPS connections, open an elevated PowerShell command window and enter the following command.
ls Cert:\LocalMachine\My
Copy the thumbprint that belongs to the SSL certificate assigned to the IP-HTTPS listener. Open an elevated command prompt window (not a PowerShell window!) and enter the following commands.
For load-balanced clusters and multisite deployments, repeat these steps on each DirectAccess server in the cluster and/or enterprise.
Summary
Once these changes have been made, only DirectAccess clients that have a computer certificate with a subject name that matches the name of its computer account in Active Directory will be allowed to establish an IP-HTTPS transition tunnel connection.
From a client perspective, DirectAccess is an IPv6 only solution. The client communicates with the DirectAccess server and intranet resources using IPv6 exclusively. To enable communication between DirectAccess clients and IPv4 only resources on the internal network, the DirectAccess servers uses two important protocol translators – DNS64 and NAT64. Unfortunately DNS64 and NAT64 provide only inbound protocol translation, so another measure is required for communication initiated outbound to connected DirectAccess clients.
ISATAP
To support outbound communication originating from the Intranet to connect DirectAccess clients, the DirectAccess server is configured as an Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) router. ISATAP is an IPv6 transition technology that allows hosts on the intranet to initiate outbound communication to DirectAccess clients on the Internet by tunneling IPv6 communication over the internal IPv4 network.
ISATAP can be enabled by populating internal DNS with a host record called ISATAP that resolves to the IPv4 address assigned to the Internal network adapter on the ISATAP router, in this case the DirectAccess server (don’t forget to remove ISATAP from the DNS global query block list!). When a client resolves ISATAP to an IP address successfully, it enables an ISATAP tunnel adapter and assigns itself an ISATAP IPv6 address. Once enabled, any host with an ISATAP tunnel adapter configured can initiate outbound communication to DirectAccess clients on the Internet.
Important note: It is not recommended to deploy ISATAP globally via DNS. See below for more details.
When configured and enabled, ISATAP opens up new and interesting network communication scenarios. For example, a helpdesk administrator can proactively initiate a remote desktop session to a remote client connected via DirectAccess to troubleshoot an application. Systems management engineers can push software out to DirectAccess clients without requiring an agent on the remote client to “phone home” to receive software updates. This model is often referred to as “manage out”.
Limitations
In the early days of DirectAccess with Windows Server 2008 R2 and Forefront UAG, configuring and enabling ISATAP as described above was standard operating procedure. However, we soon learned that there are some serious drawbacks to deploying ISATAP. While the DirectAccess manage out scenario is an important and frequently requested feature of a DirectAccess implementation, it often causes more trouble than it solves. In its default configuration, ISATAP is a global change that affects all hosts that can resolve the hostname ISATAP to an IP address. The challenge here is that this change can break or impair normal network communication for some hosts on the Intranet. For example, if an internal host is able to resolve a public hostname to an IPv6 address, it may attempt to connect to the site via ISATAP.
Unfortunately, in this scenario ISATAP does not lead to the public Internet. Rather, ISATAP is used to provide network connectivity exclusively for our DirectAccess clients. Since IPv6 is preferred in most modern operating system’s networking stacks, it can lead to failed or seriously delayed communication to Internet resources. In addition, once ISATAP is enabled globally there will be a lot of IPv6 communication taking place on the network, which in large enterprise networks can be a source of confusion for those individuals with the responsibility for monitoring the network.
ISATAP also suffers from a lack of robust monitoring tools for this very essential service. Additionally, ISATAP turns the OSI model upside down. ISATAP relies on upper-layer protocols (DNS) to provide its service. If there are issues with DNS that prevent proper name resolution, ISATAP routing will cease to function, which is fundamentally backward.
Targeted Deployment
As I mentioned earlier, ISATAP is a global setting by default. However, in most environments there will only be a few systems that will require the ability to initiate outbound communication from the internal network to remote DirectAccess clients. Typically these will be helpdesk administrators’ workstations or management systems. Today we are recommending that you deploy IPv6 on any internal systems that will participate in any DirectAccess manage out scenarios. Unfortunately this will not be possible in many cases, as additional network changes are often required to support IPv6 on the Intranet. In these cases we recommend that instead of configuring ISATAP in DNS globally, you target individual systems for ISATAP configuration as required. This can be accomplished in a number of ways.
Group Policy
This is recommended way to deploy ISATAP settings to systems that require DirectAccess manage out functionality. It is the easiest to manage and the most scalable as well. A unique ISATAP hostname (for example, DirectAccess-ISATAP) is created in the internal DNS that resolves to the internal IPv4 address of the DirectAccess server. Create a new GPO in Active Directory to assign it to management workstations using security group filtering or OU targeting. Edit the GPO setting Computer Configuration > Administrative Templates > Network > TCPIP Settings > IPv6 Transition Technologies > Set ISATAP State (Enabled and set to Enabled State) and > Set ISATAP Router Name (Enabled and enter the ISATAP hostname created previously).
PowerShell
Using PowerShell is an alternative method of configuring an individual system to use ISATAP. Although not as scalable as the group policy method, it is still very effective. On the system that requires network connectivity to DirectAccess clients, open an elevated PowerShell command window and run the following command:
Another command line method for configuring the ISATAP is to use netsh.exe. In an elevated command prompt window run the following command:
netsh interface isatap set router <NameOrIPAddress>
HOSTS File
This is the least desirable way to configure ISATAP, but I’ll mention it here because it is quick and simple and does work. On any system that requires ISATAP for DirectAccess manage out, simply edit the HOSTS file in C:\Windows\System32\Drivers\Etc and add a host record for ISATAP that resolves to the IPv4 address assigned to the internal network interface of the DirectAccess server. Obviously this is the least scalable alternative and should only be used in test environments or very small production networks.
Supportability
ISATAP is only supported for single server DirectAccess deployments. ISATAP will work when Network Load Balancing (NLB) is enabled, but it requires some additional configuration. ISATAP does not work when an external load balancer is in use and/or multisite is enabled. To restore manage out functionality for DirectAccess for load-balanced and multisite deployments, additional infrastructure and configuration is required. Fill out the form below to request more information.
Summary
As you can see there are numerous drawbacks to configuring ISATAP on a global scale. Fortunately there are simple and effective workarounds that allow you to target specific systems for ISATAP configuration. Choose the one that works best for you and have fun managing your DirectAccess clients!
Want to enable DirectAccess manage out for System Center Configuration Manager (SCCM) remote control or Remote Desktop Connection (RDC) in load-balanced and multisite deployments? Fill out the form below for more information.
Recently I’ve 
From a client perspective, DirectAccess is an IPv6 only solution. The client communicates with the DirectAccess server and intranet resources using IPv6 exclusively. To enable communication between DirectAccess clients and IPv4 only resources on the internal network, the DirectAccess servers uses two important protocol translators – DNS64 and NAT64. Unfortunately DNS64 and NAT64 provide only inbound protocol translation, so another measure is required for communication initiated outbound to connected DirectAccess clients.
As I mentioned earlier, ISATAP is a global setting by default. However, in most environments there will only be a few systems that will require the ability to initiate outbound communication from the internal network to remote DirectAccess clients. Typically these will be helpdesk administrators’ workstations or management systems. Today we are recommending that you 
