Musings of a PC

Thoughts about Windows, TV and technology in general

Lessons Learnt Deploying DirectAccess

I’ve recently been working on a basic DirectAccess (DA) configuration, using a Windows Server 2008 R2 virtual server with 2 network interfaces to provide the DA service. The ultimate aim is to use UAG (Unified Access Gateway) to provide a more complete DA experience but a recommendation I picked up from TechEd 2011 was to build a working DA implementation with just the DA role in Windows Server so that, once that is working, you can replace the DA server with UAG and if it stops working, you know it is the UAG server you need to fix.

The company I work for has perhaps a slightly unusual network configuration in that both the DMZ and Internal networks use public IP addresses. This was done before I joined them :-). I’ve recently introduced private IP addresses to augment the number of addresses available to us but my initial implementation had both NICs on the DA server using public IP addresses.

That seems to be a configuration that Direct Access can’t handle although you won’t see any errors. The upshot of this configuration is that the 6to4 adapter on the DA server, which is used to tunnel traffic from clients with public IPv4 addresses, had three IPv6 addresses instead of two. The two you would expect to see map onto the two public IPv4 addresses used on the external NIC.

This was diagnosed by performing network captures on the client whilst trying to ping some IPv6 addresses on the internal network. If you are trying to do DirectAccess network troubleshooting, I would strongly recommend the use of Microsoft’s Network Monitor tool, even instead of other popular tools such as WireShark. One of the reasons I make this recommendation is because Network Monitor will capture traffic going through tunnel adapters such as the 6to4 adapter, whereas WireShark seems to be only able to capture traffic going through physical adapters.

When you do a packet capture on a DA client, you’ll see both the IPv4 and IPv6 traffic. What happens is that the client will wrap the IPv6 PING into an IPv4 packet, pass it across to the DA server where it then gets unpacked and the IPv6 packet sent out.

What I was seeing was that instead of the wrapped up packets going to the external IPv6 address of the DA server, they were going to the internal IPv6 address … which clearly wasn’t going to work because the internal interface isn’t reachable from outside. To solve that particular issue, I had to reconfigure the DA server’s internal NIC to use a private IP address. That stopped an address being created on the 6to4 adapter for it and that allowed the tunnelled traffic to be sent consistently to the correct destination.

The next problem I faced was that the IKE tunnel wasn’t being set up. IKE failure is typically due to certificate problems. There is a good document called DirectAccess Client Cannot Establish Tunnels to the DirectAccess Server that says:

If the DirectAccess client computer cannot establish the main and quick mode SAs for the infrastructure tunnel using the default connection security rules created by the DirectAccess Setup Wizard, the most likely problem is a certificate authentication failure. For more information, see the “IKE certificate selection process” and “IKE certificate acceptance process” sections of Public Key Certificate.

Under “IKE certificate selection process”, the document says:

IKE searches the computer store for an IPSec certificate that chains to any of the trusted CA roots identified in step 1. An IPSec certificate contains an Enhanced Key Usage (EKU) attribute with a value equal to the IP security IKE intermediate object identifier (OID) 1.3.6.1.5.5.8.2.2.

Ah, I thought! I’ve only installed a certificate with the Server Authentication OID, not the IPSec IKE intermediate OID. So, I removed that cert, installed a cert with both OIDs and tried again. Things got further … when I tried to ping an internal IPv6 address, there were AuthIP packets being exchanged but the tunnel wasn’t being established and I couldn’t see why. This proved to be a harder issue to troubleshoot so I want to share the two tools I used that ultimately got me to the right answer.

The first tool is netsh, which provides network tracing functionality at a level better than Network Monitor. As an administrator, you run:

netsh trace start scenario=directaccess capture=yes report=yes

then you reproduce the problem and then you run:

netsh trace stop

This captures all of the network traffic into an ETL file which can be opened in Network Monitor. This revealed that the AuthIP traffic was failing because of the error “authentication credentials are unacceptable”. So this was still suggesting a problem with the certificates, but what?

Enter the second troubleshooting tool – event logging for CAPI2. CAPI2 is the part of the OS that deals with certificates. It is very straightforward to turn on event logging for CAPI2. Once you’ve done that, you again reproduce the problem and then look at the event log to see what is being shown.

In my case, the CAPI2 logging showed that the client goes through a process of checking that the server’s certificate has an Enhanced Key Usage of … Client Authentication. NOT, as the TechNet article said, IPSec IKE intermediate.

Again replacing the certificate on the server, this time with a cert for client and server authentication, and the tunnel is now getting established!

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: