Direct Access lab Issue

Troubleshooting DirectAccess Client Connectivity Problems
ISSUE: Cannot resolve intranet FQDNs (root cause)

When CLIENT1 is on the Internet, it uses encrypted IPsec tunnels to the DirectAccess server (EDGE1) to access the intranet DNS server (DC1) and intranet resources. If the IPsec tunnels cannot be successfully negotiated, CLIENT1 cannot resolve intranet names or connect to intranet resources.

In this troubleshooting scenario, you will configure the DirectAccess server to use the wrong root CA for IPsec authentication and then troubleshoot the results.


Break the configuration procedure

Follow these steps to configure the DirectAccess test lab for this troubleshooting scenario.

To configure DirectAccess to use the wrong root CA for IPsec authentication

1.       Connect CLIENT1 to the Corpnet subnet. Verify that CLIENT1 can reach DC1.
2.       On EDGE1, click Start, point to Administrative Tools, and then click DirectAccess Management. In the console tree of the DirectAccess snap-in, click the Setup node.
3.       Click Edit in Step 2. On the Connectivity page, click Next.
4.       On the Certificate Components page, under Select the root certificate to which remote client certificates must chain, click Browse.
5.       In the list of certificates, click Microsoft Root Authority, click OK, and then click Finish.
6.       Click Save, and then click Finish. In DirectAccess Review, click Apply.
7.       On CLIENT1, run an administrator-level Command Prompt.
8.       In the Command Prompt window, run the gpupdate command.
9.       Disconnect CLIENT1 from the Corpnet subnet, wait 30 seconds, and then connect it to the Internet subnet.
10.   From the Command Prompt window, run the ping app1 command. This command should display the Ping request could not find host app1 message.

Step-by-step troubleshooting

From the previous procedure, it appears that DC1, the intranet DNS server, is not resolving intranet names.

To troubleshoot this scenario

1.       On CLIENT1, from the Command Prompt window, run the netsh namespace show effective command. You should see the two DirectAccess NRPT rules.
2.       From the Command Prompt window, ping the IPv6 address listed in the .corp.contoso.com NRPT rule.
3.       From the Command Prompt window, use the nslookup -q=aaaa IntranetFQDNIntranetDNSServerIPv6Address command to resolve the fully qualified domain name (FQDN) for APP1 (app1.corp.contoso.com).
4.       You should not receive a response from DC1, which indicates a possible issue with creating the IPsec tunnels to EDGE1. The next step is to verify that CLIENT1 has established IPsec SAs with EDGE1.
5.       Click Start, type wf.msc, and then press ENTER.
6.       In the console tree, open Monitoring/Security Associations/Main Mode and Monitoring/Security Associations/Quick Mode. There should be no IPsec SAs.
7.       From the Command Prompt window, run the netsh advfirewall monitor show currentprofile command. This should display the Unidentified network in the public profile.
8.       On DC1, run an administrator-level Command Prompt.
9.       In the Command Prompt window, run the netsh –c advfirewall command.
10.   From the netsh advfirewall prompt, run the set store gpo=”corp.contoso.com\DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}” command.
11.   From the netsh advfirewall prompt, run the consec show rule name=”DirectAccess Policy-ClientToDnsDc” command. Note the value of Auth1CAName.
12.   From the netsh advfirewall prompt, run the exit command.
13.   From the Certificates (Local Computer)\Personal\Certificates node of the Certificates snap-in, obtain properties of the EDGE1.corp.contoso.com certificate. Click the Details tab and then click the Issuer field. Notice how the name of the CA differs from that for the Auth1CAName value in step 10.

This is the root cause of the problem. The connection security rules for DirectAccess connectivity require that the certificates being used for IPsec authentication chain a specific root CA. Because none of the certificates issued to EDGE1 and CLIENT1 chain to the Microsoft Root Authority, certificate authentication cannot complete and the IPsec tunnels needed to access the Intranet subnet cannot be established.

Correct the configuration procedure

Follow these steps to correct the configuration of the DirectAccess test lab for this troubleshooting scenario.

To configure DirectAccess to use the correct root CA for IPsec authentication

1.       Connect CLIENT1 to the Corpnet subnet. Verify that CLIENT1 can reach DC1.
2.       On EDGE1, run the DirectAccess Management snap-in, and then click the Setup node in the console tree.
3.       Click Edit in Step 2. On the Connectivity page, click Next.
4.       On the Certificate Components page, click Browse under Select the root certificate to which remote client certificates must chain.
5.       In the list of certificates, click corp-DC1-DA, click OK, and then click Finish.
6.       Click Save, and then click Finish. In DirectAccess Review, click Apply.
7.       On CLIENT1, run an administrator-level Command Prompt.
8.       In the Command Prompt window, run the gpupdate command.
9.       Disconnect CLIENT1 from the Corpnet subnet, wait 30 seconds, and then connect it to the Internet subnet.
10.   From the Command Prompt window, run the ping app1 command. This command should be successful.

One thought on “Direct Access lab Issue

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s