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.
Break the configuration procedure
Step-by-step troubleshooting
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.
|
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.
|
Feel free to ask any questions..
ReplyDelete