General Methodology for Troubleshooting DirectAccess Connections

Updated: April 25, 2011

Applies To: Windows Server 2008 R2

DirectAccess connections initiated by DirectAccess clients occur in the following stages:

  1. Internet Protocol version 6 (IPv6) connectivity to the DirectAccess server.

  2. Negotiation of protection of DirectAccess traffic with the DirectAccess server (for the full intranet and selected server access models).

  3. IPv6 connectivity to the intranet resource.

  4. Negotiation of protection of DirectAccess traffic with the intranet server (for the selected server and end-to-end access models).

Use the following process as a general methodology to step through the requirements for a DirectAccess client on the Internet to successfully access an intranet resource:

  1. The DirectAccess client computer must be running Windows 7 Ultimate Edition, Windows 7 Enterprise Edition, or Windows Server 2008 R2.

  2. The DirectAccess client computer must be a member of an Active Directory Domain Services (AD DS) domain and its computer account must be a member of one of the security groups configured in step 1 of the DirectAccess Setup Wizard.

  3. The DirectAccess client computer must have received computer configuration Group Policy settings for DirectAccess.

    To verify, use the Resultant Set of Policy snap-in and ensure that DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12} appears in the list of computer configuration Group Policy objects associated with the DirectAccess client computer.

  4. The DirectAccess server computer must have received computer configuration Group Policy settings for DirectAccess.

    To verify, use the Resultant Set of Policy snap-in and ensure that DirectAccess Policy-{ab991ef0-6fa9-4bd9-bc42-3c397e8ad300} appears in the list of computer configuration Group Policy objects associated with the DirectAccess server computer.

  5. The DirectAccess client must have a global IPv6 address.

    Use the ipconfig command to display the Transmission Control Protocol/Internet Protocol (TCP/IP) configuration. Is there an IPv6 address assigned to an interface that begins with 2 or 3?

    If yes, go to step 6.

    If not, use the netsh interface 6to4 show relay, netsh interface teredo show state, and netsh interface httpstunnel show interfaces commands on the DirectAccess client and server to verify the configuration of 6to4, Teredo, and Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS).

Note

If the DirectAccess client is connected to the Internet Protocol version 4 (IPv4) Internet, check the IPv4 address assigned by the Internet service provider (ISP) or local router. For a public IPv4 address, your Tunnel adapter 6TO4 Adapter should be configured with an address that starts with 2002. The Tunnel adapter 6TO4 Adapter should also be assigned a default gateway. For a private IPv4 address, your Teredo interface should be configured with an address that starts with 2001.
For IP-HTTPS, look at the Tunnel adapter iphttpsinterface. Unless you had a native IPv6 infrastructure in place prior to running the DirectAccess Setup Wizard, the Tunnel adapter iphttpsinterface should be configured with an address that starts with 2002. For more information, see Cannot Reach the DirectAccess Server with IP-HTTPS.
If you have configured force tunneling, only the Tunnel adapter iphttpsinterface is enabled.

For more information and additional troubleshooting steps, see [Fixing Connectivity Issues Between the DirectAccess Client and the DirectAccess Server over the Internet](ee844100\(v=ws.10\).md).  
  
  1. The DirectAccess client must be able to reach the IPv6 addresses of the DirectAccess server.

    Use the ipconfig command on the DirectAccess server to display the TCP/IP configuration. Note the global IPv6 addresses of the DirectAccess server (those starting with 2 or 3). From the DirectAccess client, ping any of the global IPv6 addresses of the DirectAccess server, starting with the IPv6 addresses that begin with 2002.

    If successful, go to step 7.

    If not successful, troubleshoot the IPv6 reachability between the DirectAccess client and server. For more information and additional troubleshooting steps, see Fixing Connectivity Issues Between the DirectAccess Client and the DirectAccess Server over the Internet.

  2. The intranet servers have a global IPv6 address.

    Use the ipconfig command on the intranet server to display the TCP/IP configuration. Is there an IPv6 address assigned to an interface that begins with 2 or 3?

    If yes, go to step 8.

    If not, troubleshoot the IPv6 infrastructure on your intranet. For Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), ensure that your Domain Name System (DNS) servers running Windows Server 2008 with Service Pack 2 or later have the name ISATAP removed from their global query block lists. Additionally, verify that the DirectAccess server has registered an ISATAP Host (A) record in the intranet DNS. For additional information and troubleshooting steps, see DirectAccess Client Cannot Access Intranet Resources.

Note

If you are using a NAT64, the intranet server might not have a global IPv6 address. In this case, ensure that the NAT64 has a global IPv6 address.

  1. The DirectAccess client on the Internet must correctly determine that it is not on the intranet.

    Use the netsh dnsclient show state command to display the Name Resolution Policy Table (NRPT) options. The determined network location is displayed in the Machine Location field (Outside corporate network or Inside corporate network).

    If the DirectAccess client has correctly determined that it is outside the corporate network (not on the intranet), go to step 9.

    If the DirectAccess client has incorrectly determined that it is inside the corporate network (on the intranet), use the netsh namespace show policy command to display the NRPT rules configured through Group Policy. There should be NRPT rules for the intranet namespace and an exemption rule for the fully qualified domain name (FQDN) of the network location server.

    Use the reg query HKLM\software\policies\microsoft\windows\NetworkConnectivityStatusIndicator\CorporateConnectivity /v DomainLocationDeterminationUrl command to display the network location uniform resource locator (URL).

    Verify that the FQDN from this URL either does not match the DNS suffix for your intranet namespace in the NRPT or matches an exemption rule in the NRPT.

    For additional information and troubleshooting steps, see DirectAccess Client Determines that it is on the Intranet When on the Internet.

  2. The DirectAccess client must not be assigned the domain firewall profile.

    Use the netsh advfirewall monitor show currentprofile command to display the attached networks and their determined firewall profiles. None of your networks should be assigned the domain profile.

    If none of your networks have been assigned the domain profile, go to step 10.

    If any of your networks has been assigned the domain profile, determine if you have an active remote access virtual private network (VPN) connection or a domain controller that is available on the Internet.

  3. The DirectAccess client must have IPv6 reachability to its intranet DNS servers.

    From the display of the netsh namespace show effectivepolicy command, obtain the IPv6 addresses of your intranet DNS servers. Ping these IPv6 addresses from the DirectAccess client.

    If successful, go to step 11.

    If not successful, troubleshoot the IPv6 reachability between the DirectAccess client and the intranet DNS servers.

    Ensure that your DirectAccess server has only a single IPv4 default gateway that is configured on the Internet interface. Also ensure that your DirectAccess server has been configured with the set of IPv4 routes on the intranet interface that allow it to access all of the IPv4 destinations of your intranet.

Note

The use of the Ping.exe tool assumes the default global Internet Protocol security (IPsec) settings that exempt Internet Control Message Protocol (ICMP) traffic from IPsec protection.

  1. The DirectAccess client must be able to use intranet DNS servers to resolve intranet FQDNs.

    Use the nslookup –q=aaaa IntranetFQDN IntranetDNSServerIPv6Address command to resolve the names of intranet servers (example: nslookup –q=aaaa dc1.corp.contoso.com 2002:836b:2:1::5efe:10.0.0.1). The Nslookup.exe tool should display the IPv6 addresses of the specified intranet server.

    If the Nslookup.exe tool performs successful name resolution, go to step 12.

    If there is no response from the intranet DNS server, test DNS name resolution from an intranet computer with the nslookup –q=aaaa IntranetFQDN IntranetDNSServerIPv6Address command. If there is no response, ensure that the DNS Server service on Windows-based DNS servers is listening on its assigned IPv6 addresses. Use the Interfaces tab for the properties of the DNS server in the DNS Manager snap-in. Otherwise, go to step 14.

    If the name was not found, determine why the corresponding AAAA record is not in your intranet DNS.

    For additional information and troubleshooting steps, see DirectAccess Client Cannot Resolve Names with Intranet DNS Servers.

  2. The DirectAccess client must have reachability to the intranet servers.

    Use the Ping.exe tool to ping the IPv6 addresses of intranet servers.

    If successful, go to step 13.

    If not successful, troubleshoot the IPv6 reachability between the DirectAccess client and the intranet servers.

Note

The use of the Ping.exe tool assumes the default global IPsec settings that exempt ICMP traffic from IPsec protection.

  1. The DirectAccess client must be able to communicate with intranet servers using application layer protocols.

    Use the appropriate program to access the intranet server. If File and Printer Sharing is enabled on the intranet server, you can test application layer protocol access (beyond the use of the Ping.exe tool) with the **net view \\**IntranetFQDN command.

    The application on the DirectAccess client must be IPv6-capable. The application on the intranet server must be IPv6-capable or you must use an intermediate NAT64/DNS64, such as the Microsoft Forefront Unified Access Gateway (UAG) 2010.

    If not successful, go to step 14.

  2. For the full intranet or selected server access models, the DirectAccess client must be able to successfully negotiate main mode and quick mode IPsec security associations (SAs) with the DirectAccess server for the infrastructure tunnel.

    On the DirectAccess client, use the Services snap-in or the sc query mpssvc command at a Windows command prompt to ensure that the Windows Firewall service is running. If you are using a third-party host firewall, see DirectAccess and Third-party Host Firewalls.

    On the DirectAccess client, use the Windows Firewall with Advanced Security snap-in or the netsh advfirewall monitor show mmsa and netsh advfirewall monitor show qmsa commands to determine if there are main mode and quick mode SAs to the IPv6 address 2002:WWXX:YYZZ::WWXX:YYZZ. WWXX:YYZZ is the colon-hexadecimal representation of the first consecutive public IPv4 address assigned to the Internet interface of the DirectAccess server. For example, for 131.107.0.1, the corresponding IPv6 address is 2002:836b:1::836b:1 (131=0x83, 107=0x6b).

    If successful, go to step 15.

    If not successful, use the nltest /dsgetdc: /force command on the DirectAccess server to ensure that it can access a domain controller. If there are no domain controllers listed, troubleshoot the lack of discoverability and connectivity between the DirectAccess server and an Active Directory domain controller.

    Ensure that the DirectAccess client and DirectAccess server have the proper certificates for IPsec peer authentication.

    If the proper certificates are installed on the DirectAccess client and DirectAccess server, use Windows Firewall tracing on the DirectAccess client and analyze the contents of the Wfpdiag.xml file. For more information, see Network Diagnostics and Tracing.

  3. For the full intranet or selected server access models, the DirectAccess client must be able to successfully negotiate main mode and quick mode IPsec SAs with the DirectAccess server for the intranet tunnel.

    Verify that you have logged on to the DirectAccess client computer with a domain account. Local computer accounts do not have the credentials to authenticate the intranet tunnel.

    On the DirectAccess client, use the Windows Firewall with Advanced Security snap-in or the netsh advfirewall monitor show mmsa and netsh advfirewall monitor show qmsa commands to determine if there are main mode and quick mode SAs to the IPv6 address 2002:RRSS:TTUU::RRSS:TTUU. RRSS:TTUU is the colon-hexadecimal representation of the second consecutive IPv4 address assigned to the Internet interface of the DirectAccess server.

    If the SAs exist and you are using a NAT64 to reach the intranet server, verify that the NAT64 supports translating the application protocol. Some protocols embed IP address information in the packet payload and cannot be used across some NAT64s.

    If successful, go to step 16.

    If not successful, use the nltest /dsgetdc: /force command on the DirectAccess server to ensure that it has access to a domain controller. If there are no domain controllers listed, troubleshoot the lack of discoverability and connectivity between the DirectAccess server and Active Directory.

    Use the nltest /dsgetdc: /force command on the DirectAccess client to ensure that it has access to a domain controller. If there are no domain controllers listed, ensure that the IPv6-capable domain controllers that are being used by DirectAccess clients are using site-less locator records in DNS.

    Ensure that the DirectAccess client and DirectAccess server have the proper certificates for IPsec peer authentication.

    If the proper certificates are installed on the DirectAccess client and DirectAccess server, use Windows Firewall tracing on the DirectAccess client and analyze the contents of the Wfpdiag.xml file. For more information, see Network Diagnostics and Tracing.

    For additional information and troubleshooting steps, see DirectAccess Client Cannot Establish Tunnels to the DirectAccess Server.

  4. For the end-to-end access model or the selected servers in the selected server access model, the DirectAccess client must be able to successfully negotiate main mode and quick mode IPsec SAs with the intranet or selected server.

    On the DirectAccess client, use the Windows Firewall with Advanced Security snap-in or the netsh advfirewall monitor show mmsa and netsh advfirewall monitor show qmsa commands to determine if there are main mode and quick mode SAs to the IPv6 address of the intranet or selected server.

    If not successful, use the nltest /dsgetdc: /force command on the intranet or selected server to ensure that it has access to a domain controller. If there are no domain controllers listed, troubleshoot the lack of discoverability and connectivity between the intranet or selected server and Active Directory.

    Use the nltest /dsgetdc: /force command on the DirectAccess client to ensure that it has access to a domain controller. If there are no domain controllers listed, ensure that the IPv6-capable domain controllers that are being used by DirectAccess clients are using Service Location (SRV) records in DNS that are not specific to an Active Directory site.

    Ensure that the DirectAccess client and intranet or selected server have the proper certificates for IPsec peer authentication.

    If the proper certificates are installed on the DirectAccess client and intranet or selected server, use Windows Firewall tracing on the DirectAccess client and analyze the contents of the Wfpdiag.xml file. For more information, see Network Diagnostics and Tracing.

    For additional information and troubleshooting steps, see Cannot Create Protected Connections to an Intranet Resource.

To troubleshoot DirectAccess connections on the DirectAccess client using the DirectAccess Connectivity Assistant (DCA), see Using the DCA Software.