DirectAccess Client Cannot Establish Tunnels to the DirectAccess Server

  • Article

Updated: November 18, 2009

Applies To: Windows Server 2008 R2

A DirectAccess client that has determined that it is not on the intranet will have effective DirectAccess-based rules in its Name Resolution Policy Table (NRPT). These rules instruct the DirectAccess client to send Domain Name System (DNS) queries that match the intranet namespace to an intranet DNS server. When the DirectAccess client attempts to find a domain controller, it must resolve names for which the DNS suffix matches the intranet namespace and a corresponding rule in the effective NRPT. But before a DNS query can be sent to the intranet DNS server, the infrastructure tunnel must be established.

After the infrastructure tunnel is successfully established, the DirectAccess client sends the DNS query to locate a domain controller. The DirectAccess client then connects to the domain controller, performs a computer-based domain logon, and connects to other infrastructure servers as needed to perform computer-based start-up functions, such as performing a health evaluation and obtaining a health certificate with Network Access Protection (NAP).

When the user logs on to the computer and a process in the context of the user account attempts to access an intranet resource by its Internet Protocol version 6 (IPv6) address, the DirectAccess client establishes the intranet tunnel.

For both tunnels, success of the Internet Protocol security (IPsec) tunnel mode security associations (SAs) depends on the connection security rules configured on DirectAccess clients and the DirectAccess server. These rules consist of a variety of settings for the following:

  • The source or destination IPv6 addresses or address prefixes for which IPsec tunnel mode is required.

  • The tunnel endpoints (the IPv6 addresses of the DirectAccess server).

  • The authentication methods required to successfully authenticate both IPsec peers (the DirectAccess client and server).

    • For the infrastructure tunnel, the authentication methods are computer certificate and UserNTLM (using the computer’s computer account credentials).

    • For the intranet tunnel, the authentication methods are computer certificate and UserKerb (using the user’s user account credentials).

  • The encryption and data integrity methods.

The DirectAccess Setup Wizard configures a compatible set of connection security rules for the DirectAccess server and DirectAccess clients that should result in a successful negotiation of IPsec SAs for both tunnels, provided the DirectAccess client and server have certificates installed in their computer store that can be used for IPsec and validated by both IPsec peers.

If the DirectAccess client cannot successfully negotiate the two tunnels, it cannot connect to resources on the intranet.

To verify whether the DirectAccess client can successfully create the infrastructure tunnel

  1. On the DirectAccess client, start a command prompt as an administrator.

  2. On the DirectAccess client, click Start, type wf.msc, and then press ENTER.

  3. In the tree pane of the Windows Firewall with Advanced Security snap-in console, click Connection Security Rules.

    In the details pane, you should see connection security rules whose names begin with DirectAccess Policy. If not, this DirectAccess client has not received its connection security rules from computer configuration Group Policy. Verify that the DirectAccess client is running Windows 7 Ultimate Edition, Windows 7 Enterprise Edition, or Windows Server 2008 R2 and is a member of one of the security groups specified in step 1 of the DirectAccess Setup Wizard.

  4. In the tree pane of the Windows Firewall with Advanced Security snap-in console, open Monitoring\Connection Security Rules.

    In the details pane, you should see a list of connection security rules that begin with DirectAccess Policy, including rules named DirectAccess Policy-ClientToDnsDc and DirectAccess Policy-ClientCorp.

  5. If you do not see these rules, from the Command Prompt window, run the netsh advfirewall monitor show currentprofile command.

    This command displays the attached networks and their determined firewall profiles. None of your networks should be in the domain profile. 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.

  6. From the Command Prompt window, run the netsh advfirewall monitor show mmsa command.

    There should be a main mode SA with the Remote IP Address set to the IPv6 address 2002:WWXX:YYZZ::WWXX:YYZZ, in which WWXX:YYZZ is the colon hexadecimal representation of w.x.y.z, the first public Internet Protocol version 4 (IPv4) address assigned to the Internet interface of the DirectAccess server. For example, if the first public IPv4 address is 131.107.0.2, the corresponding 6to4 IPv6 address is 2002:836b:2::836b:2 (836b:2 is the colon-hexadecimal representation for 131.107.0.2). The main mode SA should also have ComputerCert for Auth1 and UserNTLM for Auth2.

  7. From the Command Prompt window, run the netsh advfirewall monitor show qmsa command.

    There should be a quick mode SA with the Remote IP Address set to the IPv6 address 2002:WWXX:YYZZ::WWXX:YYZZ, corresponding to the first public IPv4 address assigned to the Internet interface of the DirectAccess server.

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.

You can view the certificates in the local computer store on the DirectAccess client and server with the Certificates snap-in.

To ensure that the DirectAccess server can access a domain controller to validate the credentials of the DirectAccess client, run the nltest /dsgetdc: /force command at an elevated command prompt. If there are no domain controllers listed, troubleshoot the lack of discoverability and connectivity between the DirectAccess server and Active Directory.

Similarly, 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.

To perform detailed IPsec negotiation analysis, use IPsec audit events in the Windows Logs\Security event log and network tracing for DirectAccess. For more information, see Event Viewer and Network Diagnostics and Tracing.

To verify whether the DirectAccess client can successfully create the intranet tunnel

  1. On the DirectAccess client, start a command prompt as an administrator.

  2. From the Command Prompt window, run the **net view \\**IntranetFileServer command. Alternately, use your Internet Web browser to access an intranet uniform resource locator (URL) or another application to access an intranet resource.

  3. From the Command Prompt window, run the netsh advfirewall monitor show mmsa command.

    There should be a main mode SA with the Remote IP Address set to the 6to4 IPv6 address corresponding to the second public IPv4 address assigned to the Internet interface of the DirectAccess server. For example, if the first public IPv4 address is 131.107.0.3, the corresponding 6to4 IPv6 address is 2002:836b:3::836b:3 (836b:3 is the colon-hexadecimal notation for 131.107.0.3). The main mode SA should also have ComputerCert for Auth1 and UserKerb for Auth2.

  4. From the Command Prompt window, run the netsh advfirewall monitor show qmsa command.

    There should be a quick mode SA with the Remote IP Address set to the 6to4 IPv6 address corresponding to the second public IPv4 address assigned to the Internet interface of the DirectAccess server.

If the DirectAccess client computer cannot establish the main and quick mode SAs for the intranet 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.

To ensure that the DirectAccess server can access a domain controller to validate the credentials of the DirectAccess client, run the nltest /dsgetdc: /force command at an elevated command prompt. If there are no domain controllers listed, troubleshoot the lack of discoverability and connectivity between the DirectAccess server and Active Directory.

Similarly, 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.

To perform detailed IPsec negotiation analysis, use IPsec audit events in the Windows Logs\Security event log and network tracing for DirectAccess. For more information, see Event Viewer and Network Diagnostics and Tracing.

IPsec and certificate revocation checking

By default, the DirectAccess client does not perform certificate revocation checking on the certificates that it receives from IPsec peers for authentication. However, the DirectAccess server by default performs certificate revocation checking on the certificates that it receives from IPsec peers with either a weak or strong CRL check.

With weak CRL checking, IPsec will check its local certificate revocation list (CRL) cache for revoked certificates. If the certificate being examined is in the cache as revoked, authentication will fail. If it is not listed as revoked in the local CRL cache, authentication will succeed. You can view the list of CRL files in your local CRL cache with the certutil -URLcache CRL command. Weak CRL checking is the default configuration of the DirectAccess server.

With strong CRL checking, IPsec will check the certificate for revocation its local CRL cache and the published CRL distribution points. If the certificate being examined is in the cache as revoked, is listed in the CRL from the CRL distribution point as revoked, or the CRL distribution point is not accessible, authentication fails. If strong CRL checking is enabled, obtain the certificate properties of the computer certificate for the DirectAccess client, examine the CRL Distribution Point field, and verify that the DirectAccess server can access the CRL from one of the specified CRL distribution point locations. If the DirectAccess server cannot retrieve the CRL from any of these locations, all IPsec certificate authentication fails.

If strong or weak CRL checking configured on either the DirectAccess server or client, you can obtain additional information through the Windows Logs\Security event log. To view the failures for IPsec in the Windows Logs\Security event log in Event Viewer, you must enable auditing on the DirectAccess client or server with the auditpol.exe /set /SubCategory:"IPsec Main Mode","IPsec Extended Mode" /success:enable /failure:enable command.

Look for the following events in the Windows Logs\Security event log:

  • Event ID 4653: Main Mode: Failed: An IPsec Main Mode Negotiation Failed

  • Event ID 4654: Quick Mode: Failed: An IPsec Quick Mode Negotiation Failed

  • Event ID 4984: Extended Mode: Failed: An IPsec Extended Mode Negotiation Failed. The corresponding Main Mode Security Association has been deleted.

    Extended Mode failures are typically generated for problems with user authentication for tunnel mode and for IPsec authorization failures, such as when you are using smart cards for additional authorization. Event 4984 indicates that the credentials supplied are not authorized to establish the tunnel to the DirectAccess Server.

NAP health enforcement for the intranet tunnel

If NAP full enforcement mode is configured in the connection security rules for the intranet tunnel and the DirectAccess client does not receive a health certificate, the DirectAccess client will not be able to access intranet resources.

The Windows Logs\Security event log will contain an IPsec audit failure. The specific event that indicates a NAP health failure is the following:

  • MessageId=13905

  • SymbolicName=ERROR_IPSEC_IKE_AUTHORIZATION_FAILURE. SA establishment is not authorized.

To perform additional NAP health evaluation troubleshooting, see Introduction to Troubleshooting NAP and Fixing Health Certificate Problems in the Network Access Protection Troubleshooting Guide.

Smart card authorization

If you are using smart cards for an additional level of authorization and IPsec authentication fails, the Windows Logs\Security event log will contain IPsec audit failures. For smart card authorization, the authorization rules on the DirectAccess server require that a DirectAccess client specify a security identifier (SID) that indicates the user is in possession of a certificate that qualifies for the "This Organization Certificate" property.

The specific event that indicates a failure to present a smart card-based certificate during the negotiation of the intranet tunnel is the following:

  • MessageId=13906

  • SymbolicName=ERROR_IPSEC_IKE_STRONG_CRED_AUTHORIZATION_FAILURE. SA establishment is not authorized because of lack of a PKINIT-based credential of sufficient strength.

Detailed analysis of IPsec negotiation

In addition to the events in the Windows Logs\Security event log, you can use Windows Firewall tracing to capture detailed IPsec negotiation and component interaction information. For more information, see Network Diagnostics and Tracing.