SSH Administration over a DirectAccess Connection

SSH Administration over a DirectAccess ConnectionFrom a client perspective, DirectAccess is an IPv6 only solution. All communication between the DirectAccess client and server takes place exclusively over IPv6. This can make things challenging for network engineers tasked with administering network devices using SSH over a DirectAccess connection. Often network devices don’t have corresponding hostname entries in DNS, and attempting to connect directly to an IPv4 address over a DirectAccess connection will fail.

To resolve this issue, it is necessary to create internal DNS records that resolve to IPv4 addresses for each network device. With that, the DNS64 service on the DirectAccess server will create an IPv6 address for the DirectAccess client to use. The NAT64 service will then translate this IPv6 address to IPv4 and connectivity will be established.

However, for many large organizations this might not be feasible. You may have hundreds or thousands of devices on your network to administer, and creating records in DNS for all these devices will take some time. As a temporary workaround, it is possible to determine the NAT64 IPv6 address for any network device and use that for remote network administration.

The process is simple. On a client that is connected remotely via DirectAccess, resolve the name of a known internal server to an IP address. The quickest and easiest way to do that is simply to ping an internal server by its hostname and note the IPv6 address it resolves to.

SSH Administration over a DirectAccess Connection

Now copy the first 96 bits of that address (everything up to and including the 7777::) and then append the IPv4 address of the network device you wish to manage in familiar dotted-decimal notation. The IPv6 address you create should look something like this:

fd74:45f9:4fae:7777::172.16.1.254

Enter this IPv6 address in whichever tool you use to manage your network devices and it should work. Here’s an example using the popular Putty tool connecting via SSH to a network device in my lab.

SSH Administration over a DirectAccess Connection

Figure 1 – DirectAccess Client IPv6 Prefix w/Appended IPv4 Address

SSH Administration over a DirectAccess Connection

Figure 2 – Successful connection over DirectAccess with Putty.

Going forward I would strongly recommend that you make it part of your normal production implementation process and procedures to create DNS records for all network devices. In the future you’ll absolutely have to do this for IPv6, so now is a good time to get in the habit of doing this. It will make your life a lot easier, trust me!

Please note that adding entries to the local HOSTS file of a DirectAccess client does not work! The name must be resolved by the DNS64 service on the DirectAccess server in order to work properly. Although you could populate the local HOSTS file with names and IPv6 addresses using the method I described above, it would cause problems when the client was on the internal network or connected remotely using traditional client-based VPN, so it is best to avoid using the HOSTS file altogether.

3 Important Things You Need to Know about Windows 10 and DirectAccess

DirectAccess and Windows 10 - Better TogetherDirectAccess has been with us for quite some time know, having been originally introduced with Windows Server 2008 R2, later enhanced with Forefront Unified Access Gateway (UAG) 2010, and finally integrated in to the base operating system in Windows Server 2012 R2. Client support for DirectAccess begins with Windows 7 (Enterprise or Ultimate), and also includes Windows 8.x (Enterprise) and Windows 10 (Enterprise or Education).

Although Windows 7 clients are supported for DirectAccess, Windows 10 is highly preferred. Here are three important things you need to know about using Windows 10 with DirectAccess.

  1. Windows 10 Provides Improved Performance and Scalability – Windows 10 includes support for null encryption when using the IP-HTTPS IPv6 transition protocol. This eliminates the needless double-encryption performed by Windows 7 clients, and dramatically reduces the protocol overhead for clients connecting behind port-restricted firewalls. DirectAccess servers can support many more concurrent IP-HTTPS sessions with Windows 10, and it has the added benefit of making the more secure perimeter/DMZ deployment behind an edge security device performing NAT much more attractive.
  2. Windows 10 Supports Geographic Redundancy – Windows 10 includes full support for DirectAccess multisite deployments. Where Windows 7 clients had to be assigned to a single entry point, Windows 10 clients are aware of all entry points in the organization. They are able to automatically select the nearest entry point on startup, and transparently failover to another site if the current site becomes unavailable.
  3. Windows 10 Features an Enhanced Management Experience – From a troubleshooting and support perspective, Windows 10 makes things much easier. The DirectAccess connectivity assistant, an optional component for Windows 7, is now fully integrated with the Windows 10 UI. PowerShell is greatly improved and now includes many native DirectAccess configuration and troubleshooting commands.

As you can see, there are a number of significant advantages for using Windows 10 with DirectAccess. Windows 10 now supports all of the enterprise features of DirectAccess, including geographic redundancy and performance and scalability improvements. Windows 10 is also easier to troubleshoot and manage. If you’re still supporting Windows 7, DirectAccess in Windows Server 2012 R2 can certainly support them. However, without a doubt the best experience, both from an administrator’s and the end user’s perspective, is with Windows 10. Just one more reason to begin planning your migration to Windows 10 with DirectAccess today!

Need assistance with implementing  DirectAccess with Windows 10? I can help! More details here.

DirectAccess Manage Out from Windows 10 Does Not Work

Note: The issue described in this article has been resolved in Windows 10 version 1703 (Creators Update). Making these changes is no longer required after installing the Creators Update release of Windows 10.

For DirectAccess manage out deployments using ISATAP, you may encounter a scenario in which you are unable to initiate outbound connections to connected DirectAccess clients from a Windows 10 computer. Outbound connections using ISATAP from Windows 7, Windows 8, Windows Server 2008/R2, or Windows Server 2012/R2 systems work without issue.

DirectAccess Manage Out from Windows 10 Does Not Work

As it turns out, there is a bug in the Windows 10 DNS client code that prevents manage out using ISATAP from a Windows 10 client from working correctly. Thanks to the diligent effort of DirectAccess administrators Mike Piron and Jason Kuhns, a workaround has been identified. To deploy the workaround, it will be necessary to implement registry changes to alter the default behavior of the DNS resolver in Windows 10. You can implement these changes on a Windows 10 DirectAccess manage out machine by using the following PowerShell commands:

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableParallelAandAAAA -PropertyType dword -Value 1 -Force

New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\” -Name DisableServerUnreachability -PropertyType dword -Value 1 –Force

Once these registry changes have been made, you should now be able to use ISATAP for DirectAccess manage out connections from a Windows 10 machine.