Share via

Considerations When Using Ping to Troubleshoot DirectAccess Connectivity Issues

  • Article

(This content was originally posted on the Edge Man blog at http://blogs.technet.com/b/tomshinder/archive/2010/07/14/considerations-when-using-ping-to-troubleshoot-directaccess-connectivity-issues.aspx?CommentPosted=true#commentmessage. Feel free to enhance and improve it!)

========================================================================================================

You’re learning about DirectAccess and you like what you see. The next step is to build out a test lab. You can build out your own, or you can let me to the heavy lifting for you and use the UAG DirectAccess Step by Step Guide over at http://technet.microsoft.com/en-us/library/ee861167.aspx You’ll save a lot of time by using the lab I put together for you, and you’ll learn a lot about DirectAccess terminology and configuration issues.

When you do put your Test Lab together, you’ll find that there are a lot of technologies and a lot of steps involved with making it work. The reason for this is that DirectAccess is really a collection of product and platform technologies that work together to create a working remote access solution that we’ve named DirectAccess. All the components of the solution need to be configured correctly for it to work.

And that will likely be your first challenge when you start working with DirectAccess. You’ll have gone through all the steps in the Step by Step guide and BAM! It didn’t work. Don’t worry – a lot of the technologies are probably new to you. That means there’s a good chance that you missed a step. I’ve done it, other DirectAccess experts have done it. Consider this a normal part of the DirectAccess learning process. After you’ve gone through the test lab a few times, all the concepts and technologies will fall into place in your mind and you’ll actually get to a place where you’ll forget what it was like not to understand how all the DirectAccess pieces fit together.

With that in mind, I wanted to take a few minutes to talk to you about using ping to test DirectAccess connectivity. We’re all accustomed to using ping to test connectivity issues – this is something firmly ingrained in all of our years with working with the Windows network operating system. And while you definitely can take advantage of ping to help you troubleshoot DirectAccess connectivity issues, there are a few things that you need to keep in mind about ICMP and DirectAccess connectivity.

DirectAccess Tunnels are IPsec Tunnels

First, remember that DirectAccess uses IPsec tunnels between the DirectAccess client and DirectAccess server to allow DirectAccess clients access to intranet resources. There are two tunnels:

  • The Infrastructure Tunnel – the purpose of this tunnel is to allow the DirectAccess client to a subset of servers on the intranet that are required for name resolution (DNS servers) and authentication (domain controllers) and health checking (NAP servers) and remediation (update servers). There may also be other servers you want to include in this list, such as management servers (Configuration Manager). The infrastructure IPsec tunnel is established after both computer certificate and computer account (NTLMv2) authentication is successful. Enabling the user account (normally computer account) access allows the Infrastructure tunnel to come up before the user logs on.
  • The Intranet Tunnel – the purpose of this tunnel is to allow the DirectAccess clients access to the rest of the network. It should be clear that DirectAccess is not a firewall solution and should not be considered one. DirectAccess is meant to replicate the intranet experience and the DirectAccess client should be considered the same as any client on the intranet. For that reason, there are no access controls places on the DirectAccess client after the DirectAccess client authenticates with the DirectAccess server. The intranet IPsec tunnel is established after computer certificate and user account (the logged on user) (Kerberos) authentication is successful.

It is commonly said by DirectAccess experts (including myself) that all traffic moving through the DirectAccess client to resources on the intranet is through one of these tunnels. This is true for all traffic except ICMP traffic. In a UAG DirectAccess scenario, IPsec policy is configured to exempt ICMP from IPsec authentication and encryption. Therefore when you ping a resource on the intranet, you are sending those pings outside of the infrastructure and intranet IPsec DirectAccess tunnels.

Now you might be asking yourself “If the ping traffic isn’t going through the DirectAccess tunnels, how it is getting to the intranet”? That’s a good question and unless you’ve been in the IPv6  transition technology game for awhile, the answer is definitely not obvious.

A Tale of Two Tunnels

Take a look at the figure below. What I tried to draw here are two tunnels. The larger tunnel is an IPv6 transition technology tunnel. IPv6 transition technologies can be used to allow the IPv6 communications between the DirectAccess client and DirectAccess server to be carried over the IPv4 Internet. The DirectAccess client can use one of three IPv6 transition technologies over the Internet: 6to4, Teredo or IP-HTTPS. The details of each these isn’t important here.

What is important is to understand is that each of these IPv6 transition technologies tunnel IPv6 packets inside an IPv4 header. Inside of the IPv6 transition technology IPv4 tunnel is the IPsec tunnel – where IPsec is used to authenticate and encrypt the IPv6 packets. When you think about DirectAccess tunnels, you should think of two tunnels – the IPv6 transition technology tunnel and the IPsec tunnel.

http://blogs.technet.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-80-75-metablogapi/6562.image_5F00_thumb.png

The above figure shows that ICMP messages are carried over the IPv6 transition technology tunnel, but that they are outside the IPsec tunnel.  The reason why we decided to do this is to make Teredo work correctly, as Teredo requires ICMP access outside the IPv6 IPsec tunnel to determine what type of NAT device the DirectAccess client might be located.

Because of this decision, you need to be aware of a couple of issues:

  • Since the ICMP traffic is not encrypted, it can potentially be read by a device that is IPv6 transition technology aware. This information might be of interest to attackers or other curious individuals. For information on this issue, please see http://technet.microsoft.com/en-us/library/ee809059.aspx Be aware that if you force ICMP through the DirectAccess IPsec tunnels, you will not be able to use Teredo.
  • When troubleshooting DirectAccess connectivity issues, the ability to ping resources on the intranet indicates that the IPv6 transition technology is working, but does not provide any information regarding whether or not the infrastructure or intranet IPsec tunnels were established.

Before going into the details of ICMP traffic and troubleshooting, I wanted to point out where the ICMP exemptions for IPsec traffic are configured. In the first figure below you can see the Group Policy Object (GPO) for the DirectAccess servers. When you right click the Windows Firewall with Advanced Security – LDAP {GUID} entry and click Properties, you’ll see what appears in the figure right below it – in the Windows Firewall with Advanced Security dialog box, on the IPsec Settings tab. In the IPsec exemptions frame, you’ll see the Exempt ICMP from IPsec option is set to Yes.

http://blogs.technet.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-80-75-metablogapi/8244.image_5F00_thumb_5F00_1.png

 

 http://blogs.technet.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-80-75-metablogapi/2476.image_5F00_thumb_5F00_2.png

ICMP, Ping and Troubleshooting DirectAccess Connectivity

Now let’s take a look at what happens when the IPsec infrastructure and intranet tunnels fail. In this example, I took a working DirectAccess setup and broke it by configuring the UAG DirectAccess server to use the wrong root certificate for mutual computer authentication. Since the root certificate configured in the UAG DirectAccess configuration points to a root CA that didn’t issue the computer certificates used for computer certificate authentication, all IPsec tunnel connection attempts will fail.

One of the standard things we do when troubleshooting DirectAccess connections is to see if we can ping the 6to4 address of the UAG DirectAccess server itself. You can get this address by using the

netsh namespace show effectivepolicy

command on the DirectAccess client, as seen in the figure below.

http://blogs.technet.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-80-75-metablogapi/8267.image_5F00_thumb_5F00_3.png

Now that we have that address, let’s try and ping it.

http://blogs.technet.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-80-75-metablogapi/4061.image_5F00_thumb_5F00_4.png

Yay! That worked and shows that we have IPv6 connectivity with the DirectAccess server. This proves that at least the IPv6 transition technology is working enough so that we can ping the UAG DirectAccess server side of the Teredo (in this example) tunnel. What it doesn’t tell us is if the other components that allow address to resources behind the UAG DirectAccess server are functional.

To enable ICMP access to resources behind the UAG DirectAccess server, you will need to know the IPv6 address of the resource you want to connect to. This can be an ISATAP address or a native IPv6 address (or as well see later, a NAT64 address). It doesn’t matter which type – what matters is the fact that the DirectAccess client only communicates with the DirectAccess server and the networks behind it using IPv6 (except when NAT64/DNS64 is used, in which case the communications are “NATed” by the UAG DirectAccess server, so that between the DirectAccess client and the UAG DirectAccess server IPv6 is used and communications between the UAG DirectAccess server and the IPv4 resource on the intranet, IPv4 is used).

We can go to the domain controller on the network and use ipconfig /all to check it’s ISATAP address. In this example the ISATAP address of the domain controller (DC1) is 2002:836b:2:8000:5efe:10.0.0.1 so we’ll ping that ISATAP IPv6 address from the DirectAccess client on the Internet.

http://blogs.technet.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-80-75-metablogapi/3005.image_5F00_thumb_5F00_5.png

Yay again! It worked. Now we know that the Teredo tunnel between the DirectAccess client and the DirectAccess server is up, and that the Teredo relay configured on the UAG DirectAccess is working.

What About IPv4 Only Resources – How Do I Ping Them?

What if you’re not using ISATAP and you’re not using native IPv6 addresses behind the UAG DirectAccess server? This is a common scenario where you have an IPv4-only network behind the UAG DirectAccess server. In this case, you’re taking advantage of the UAG DirectAccess server’s NAT64/DNS64 capabilities. If you want to learn more about NAT64/DNS64, I highly recommend you read Meir Mendelovich’s excellent coverage of this subject over at  http://blogs.technet.com/b/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx

The problem we have to solve is how do we figure out what the NAT64 address is of an IPv4 only host? Well, the answer comes from an exceptional blog post by Ben Bernstein over at http://blogs.technet.com/b/edgeaccessblog/archive/2009/10/13/deep-dive-into-uag-directaccess-ipv6-and-directaccess.aspx 

The UAG NAT64 address of an IPv4 only host is:

2002:WWXX:YYZZ:8001:[Hex of IPv4 address] /96 (the /96 means that the prefix is 96 bits of the 128 bit IPv6 address)

The WWXX:YYZZ is the Hex representation of the first of the two consecutive IPv4 public address on the UAG DirectAccess Server. You can figure this out if you like, but UAG has already done this work for you. If you look in the figure above, you can see these components of the IPv6 address:

836b:2: – this is the WWXX:YYZZ Hex representation of the IPv4 address

8000: – this is the value used to represent the ISATAP prefix (this is covered in more detail in Ben’s article if you want more information in this)

What we can do is take this information and build out our NAT64 address for the IPv4 only resource. First, we can define our prefix, which is:

2002:836b:2:8001 /96 (the 8001 value is used to represent the NAT64 prefix)

The last 32 bits of the address is Hex representation of the IPv4 only resource. In this example, the IPv4 only resource has the IPv4 address 10.0.0.4. We convert to this to Hex:

10 = 0a in Hex (8 bits)

**0  ** = 00 in Hex (8 bits)

0   = 00 in Hex (8 bits)

4   = 04 in Hex (8 bits)

Or – 0a00:0004 (32 bits represented by two 16 bit blocks)

Now we can put our prefix and address together and get:

2002:836b:2:8001:0000:0000:0a00:0004 /96

You might be wondering where the 0000:0000 entry came from. First, you need to know that each “block” (the value between the colons) represents 16 bits. There are eight blocks in a 128 bit IPv6 address. We defined the first 64 bits of the NAT64 prefix with the four blocks 2002:836b:2:8001. However, the NAT64 prefix is 96 bits, so we need to add another 32 bits to the prefix to make it add up to 96. We can do this by adding two blocks of zeros. That gives us the 96 bit prefix. Then we just append the Hex presentation of the 32 bit IPv4 address at the end.

NOTE:
There is something called “zero suppression” when describing IPv6 addresses where leading zeros can be left out and where they can be replaced with a double colon “::”. We don’t need to get into that now, but you’ll notice that is done automatically by the operating system when it converts the WWXX:YYZZ and also in the ping responses.

Let’s give it a try.

http://blogs.technet.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-80-75-metablogapi/8203.image_5F00_thumb_5F00_7.png 

Yay for a third time! It worked again. This proves that we have ICMP connectivity to both IPv6 and IPv4 resources on the intranet. At this point we must be feeling pretty good, as we’ve successfully pinged the UAG DirectAccess server and a IPv4 and IPv6 resources on the intranet.

But what about traffic isn’t ICMP? A quick check can be done by using the web browser. In the figure below I’m using the ISATAP address of a web server on the intranet. Notice that if you want to use IPv6 addresses in Internet Explorer, you have to surround them with brackets.

http://blogs.technet.com/cfs-file.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-80-75-metablogapi/8105.image_5F00_thumb_5F00_8.png

This connection fails because it’s using HTTP, which isn’t ICMP. The reason for the failure is that in order to transport HTTP, the DirectAccess IPsec tunnels must be available. And because I broke IPsec, there are no tunnels. You can prove that to yourself by using the Windows Firewall with Advanced Security console and finding no Main Mode or Quick Mode Security Associations. There is a process to troubleshoot IPsec tunnel establishment failure, but that’s not why we’re here today :)

Summary

The key points I want you to remember from this article include:

  • DirectAccess uses two tunnels: IPv6 transition technology tunnels and an IPsec tunnels
  • ICMP is exempted from IPsec protection
  • You can ping the UAG DirectAccess server and resources behind it without establishing an IPsec tunnel
  • If the IPsec tunnels do not come up, you will not be able to use any non-ICMP protocol to connect to the the UAG DirectAccess server or resources behind it
  • The ability to ping gives you no information about IPsec tunnel establishment.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft ISD iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder