All posts tagged DNS64

Native PowerShell commands in Windows 10 make DirectAccess troubleshooting much easier than older operating systems like Windows 7. For example, with one PowerShell command an administrator can quickly determine if a DirectAccess client has received the DirectAccess client settings policy. In addition, PowerShell can be used to view the status of the connection and retrieve additional information or error codes that can be helpful for determining the cause of a failed connection. Further, PowerShell can also be used to review configuration details and perform other troubleshooting and connectivity validation tasks.

Here are my top 5 PowerShell commands for troubleshooting DirectAccess on Windows 10.

1. Get-DAClientExperienceConfiguration

Ensuring that the DirectAccess Client Settings group policy has been applied to the client is one of the first steps in troubleshooting failed DirectAccess connections. While it is possible to use gpresult to do this, using the Get-DAClientExperienceConfiguration PowerShell command is much simpler. If DirectAccess client settings have been applied, the output of the command will include information such as the IPsec tunnel endpoint IPv6 addresses and the Network Connectivity Assistant (NCA) corporate resource URL. If DirectAccess client settings have not been applied, this information will be missing.

Performance improvements first introduced in Windows 8 have made IP-HTTPS the IPv6 transition technology of choice when it comes to supporting DirectAccess client connectivity. Also, if the DirectAccess server is located behind an edge device performing Network Address Translation (NAT), IP-HTTPS is the only supported transition technology. Using the Get-NetIPHttpsState PowerShell command, the DirectAccess administrator can quickly determine if the IP-HTTPS connection was successful. If it was not, the command will return an error code and interface status that will indicate why the IP-HTTPS connection was unsuccessful.

Figure 3. Get-NetIPHttpsState

3. Get-NetIPHttpsConfiguration

When troubleshooting IP-HTTPS connection failures, it is necessary to obtain additional information to continue the troubleshooting process. Using the Get-NetIPHttpsConfiguration PowerShell command, the DirectAccess administrator can obtain the public hostname for the DirectAccess server and ensure that the name resolves to the correct IP address in DNS and that it is reachable on TCP port 443.

Figure 4. Get-NetIPHttpsConfiguration

4. Resolve-DnsName

Using the Resolve-DnsName PowerShell command is crucial when performing any name resolution tasks on the DirectAccess client. This is because Resolve-DnsName is aware of the Name Resolution Policy Table (NRPT) and will direct name resolution requests accordingly. Tools like nslookup are DNS server testing tools and are unaware of the NRPT. Typically they do not yield expected results when testing name resolution on a DirectAccess client.

Figure 5. Name resolution results from Resolve-DnsName and nslookup.

5. Get-DnsClientNrptPolicy

Often the cause of DirectAccess client connectivity issues is a misconfigured NRPT. Using the Get-DnsClientNrptPolicy PowerShell command the DirectAccess administrator can validate that name resolution requests for host names in any internal namespaces are being sent to the DirectAccess DNS64 IPv6 address.

The seamless and transparent nature of DirectAccess makes it wonderfully easy to use. In most cases, it requires no user interaction at all to access internal corporate resources while away from the office. This enables users to be more productive. At the same time, it offers important connectivity benefits for IT administrators and systems management engineers as well.

Always Managed

DirectAccess clients are automatically connected to the corporate network any time they have a working Internet connection. Having consistent corporate network connectivity means they receive Active Directory group policy updates on a regular basis, just as on-premises systems do. Importantly, they check in with internal management systems such as System Center Configuration Manager (SCCM) and Windows Server Update Services (WSUS) servers, enabling them to receive updates in a timely manner. Thus, DirectAccess clients are better managed, allowing administrators to more effectively maintain the configuration state and security posture for all their managed systems, including those that are predominantly field-based. This is especially crucial considering the prevalence WannaCry, Cryptolocker, and a variety of other types of ransomware.

DirectAccess Manage Out

When manage out is configured with DirectAccess, hosts on the internal network can initiate connections outbound to remote connected DirectAccess clients. SCCM Remote Control and Remote Desktop Connection (RDC) are commonly used to remotely connect to systems for troubleshooting and support. With DirectAccess manage out enabled, these and other popular administrative tools such as VNC, Windows Remote Assistance, and PowerShell remoting can also be used to manage remote DirectAccess clients in the field. In addition, enabling manage out allows for the proactive installation of agents and other software on remote clients, such as the SCCM and System Center Operation Manager (SCOM) agents, third-party management agents, antivirus and antimalware software, and more. A user does not have to be logged on to their machine for manage out to work.

IPv6

DirectAccess manage out requires that connections initiated by machines on the internal network to remote-connected DirectAccess clients must be made using IPv6. This is because DirectAccess clients use IPv6 exclusively to connect to the DirectAccess server. To enable connectivity over the public IPv4 Internet, clients use IPv6 transition technologies (6to4, Teredo, IP-HTTPS), and IPv6 translation components on the server (DNS64 and NAT64) enable clients to communicate with internal IPv4 resources. However, DNS64 and NAT64 only translate IPv6 to IPv4 inbound. They do not work in reverse.

Native or Transition?

It is recommended that IPv6 be deployed on the internal network to enable DirectAccess manage out. This is not a trivial task, and many organizations can’t justify the deployment for just this one specific use case. As an alternative, IPv6 can be configured with an IPv6 transition technology, specifically the Intrasite Automatic Tunnel Addressing Protocol (ISATAP). ISATAP functions as an IPv6 overlay network, allowing internal hosts to obtain IPv6 addresses and routing information from an ISATAP router to support manage out for DirectAccess clients.

ISATAP

When DirectAccess is installed, the server is automatically configured as an ISATAP router. Guidance for configuring ISATAP clients can be found here. Using ISATAP can be an effective approach to enabling DirectAccess manage out for SCCM when native IPv6 is not available, but it is not without its drawbacks.

• Using the DirectAccess server for ISATAP is only supported with single server DirectAccess deployments.
• Using the DirectAccess server for ISATAP does work when using Network Load Balancing (NLB) with some additional configuration, but it is not supported.
• Using the DirectAccess server for ISATAP does not work when an external load balancer is used, or if multisite is enabled.

ISATAP with Load Balancing and Multisite

It is technically possible to enable DirectAccess manage out for SCCM using ISATAP in load-balanced and multisite DirectAccess deployments, however. It involves deploying a separate ISATAP router and some custom configuration, but once in place it works perfectly. I offer this service to my customers as part of a consulting engagement. If you’re interested in restoring DirectAccess manage out functionality to support SCCM remote control, RDC, or VNC in load-balanced or multisite DirectAccess deployments, fill out the form below and I’ll provide you with more information.

DirectAccess uses IPv6 exclusively for communication between the DirectAccess client and server. The DNS64 and NAT64 services running on the DirectAccess server allow the client to connect to IPv4-only resources on the corporate network. Although no IPv6 knowledge is necessary to implement DirectAccess, it is most certainly requiredto support it going forward. A fundamental understanding of IPv6 is vital when it comes to troubleshooting DirectAccess connectivity issues, so learning IPv6 is critically important for the DirectAccess administrator.

To help you learn more about IPv6, here are three essential resources I think you will find helpful!

Understanding IPv6 (Joe Davies) – This is an excellent reference for the IPv6 protocol and should be on every DirectAccess administrator’s desk. This book provides detailed documentation and explanations for the IPv6 protocol including IPv6 transition protocols, which are commonly used with DirectAccess.

IPv6 Address Planning (Tom Coffeen) – This book is an optional read for DirectAccess administrators, but a recommended one still. There is no IPv6 address planning required to implement DirectAccess, as most commonly IPv6 addressing happens automatically. However, this book will help you understand IPv6 subnetting, which can be helpful for fully understanding DirectAccess.

If you prefer video training, be sure to check out this great course on Pluralsight from Ed Horley. Don’t be afraid of IPv6. Embrace it! Start learning IPv6 today!

When troubleshooting name resolution issues on a Windows client, NSlookup is an essential tool. However, it is important to understand that using NSlookup on a DirectAccess client might not always work as you expect. Although using NSlookup on a DirectAccess client will work normally when the client is on the corporate network, it will not provide the correct results to queries for internal hostnames when the DirectAccess client is outside of the corporate network without taking additional steps. This is because when a DirectAccess client is outside the corporate network, the Name Resolution Policy Table (NRPT) is enabled. The NRPT provides policy-based name resolution routing for DirectAccess clients, sending name resolution requests for certain namespaces to specific DNS servers. You can view the NRPT on a Windows 8.x DirectAccess client by issuing the following PowerShell command:

Get-DnsClientNrptPolicy

You can view the NRPT on a Windows 7 DirectAccess client by issuing the following netsh command:

netsh namespace show policy

Here you’ll notice that the namespace .lab.richardhicks.net is configured to use the DNS64 service running on the DirectAccess server at 2002:62bd:d898:3333::1. Notice also that the host nls.lab.richardhicks.net is not configured to use a DNS server. This effectively exempts this host from the NRPT, forcing name resolution requests for this Fully-Qualified Domain Name (FQDN) to be delivered to the DNS servers configured on the network adapter.

A Working Example

With the NRPT enabled, which occurs whenever the DirectAccess client is outside of the corporate network, a name resolution request for app1.lab.richardhicks.net would be sent to the DNS64 service on the DirectAccess server. A name resolution request for technet.microsoft.com would be sent to the DNS servers assigned to the network adapter because the NRPT contains no entry for this namespace. And even though the host nls.lab.richardhicks.net is a part of the internal namespace, a name resolution request for this host would also be sent to the DNS servers assigned to the network adapter because it has been specifically exempted from the NRPT.

NSlookup

The NSlookup utility is unaware of the NRPT. Whenever you use NSlookup it will, by default, automatically send queries directly to the DNS servers configured on the network adapter, regardless of the NRPT. If you wish to use NSlookup to test name resolution for external hostnames, use it as you normally would. However, if you wish to use NSlookup to resolve internal hostnames over the DirectAccess connection, you will need to tell NSlookup to use the DNS64 service running on the DirectAccess server. You can do this by running NSlookup interactively and using the server command to point it to the IPv6 address of the DNS64 service, which you can find in the NRPT.

This also applies to the PowerShell cmdlet Resolve-DNSname. Here you’ll use the -Server switch to specify the DNS64 server’s IPv6 address.

Joseph Davies’ latest book Understanding IPv6: Your Essential Guide to IPv6 on Windows Networks is now available. Now in its third edition, this book is an excellent reference for systems administrators and network engineers wanting to learn the fundamentals of IPv6, and specifically how IPv6 is deployed on Microsoft networks. The book explains in detail the inner workings of the IPv6 protocol, including addressing, IPv6 headers, ICMPv6, and neighbor discover. In addition the book also covers IPv6 name resolution, routing, and transition technologies such as ISATAP, 6to4, Teredo, IP-HTTPS, DNS64, and NAT64. New in this addition is a chapter covering DirectAccess in Windows Server 2008 R2 and Windows Server 2012. Get your copy today!

IPv6 is one of the main underpinnings of DirectAccess. All communication between the DirectAccess client and the DirectAccess server and corporate network resources takes place using IPv6 only. DNS64 and NAT64, the protocol translators for DNS and NAT, address these concerns by translating native IPv6 traffic to IPv4, allowing the DirectAccess client to communicate with systems on the corporate network that are running only IPv4. This significantly reduces the barrier to entry for the adoption of DirectAccess as a remote access solution, but it doesn’t eliminate the requirement for IPv6 altogether. When DNS64 and NAT64 are leveraged, either as part of UAG DirectAccess or the unified remote access role in Windows Server 2012, it is important to remember that the DirectAccess client still communicates with the DirectAccess server using IPv6. It is for this reason that I strongly recommend and encourage systems and network engineers to start learning IPv6 today! I realize that IPv6 looks a bit scary from the outside. The address space is 128-bit and IPv6 addresses are written in hexadecimal, which can be quite daunting for many, me included. There are some new acronyms to learn as well. However, do you recall a time when you didn’t know IPv4? I certainly do! I remember first learning it and thinking I would never get it. Subnet masks? Dotted decimal notation? CIDR? They were completely foreign concepts. Eventually you learn it, gain experience deploying and troubleshooting it, and soon thereafter it becomes second nature. That is most people’s experience with IPv4, and it will be no different with IPv6. It will just take time to learn this new technology.

So, don’t be overwhelmed by IPv6! It’s not like you have to learn an entire new networking model top to bottom. After all, the bottom line is that it is just layer 3 – IP. Begin reading books on the subject and more importantly start deploying it in a lab environment. Soon you’ll have valuable knowledge and experience with the IPv6 protocol which will make you a more complete engineer. To get started, here are a few resources I’d recommend as you begin your quest for IPv6 knowledge and experience:

Understanding IPv6 – This is an excellent book to read to start learning about IPv6. Joe Davies is an outstanding writer and the third edition of this book is due out this summer. Ed Horley, a preeminent expert in the field of IPv6 and co-chair of the California IPv6 Task Force is serving as the technical reviewer so it is sure to be outstanding.

IPv6 test lab guide – Test lab guides are essential for learning new features of the Microsoft operating system and applications. The IPv6 test lab guide provides detailed and prescriptive guidance for deploying IPv6 on a Microsoft network.