Cannot Create Protected Connections to an Intranet Resource

Updated: November 18, 2009

Applies To: Windows Server 2008 R2

For the selected server or end-to-end access models, DirectAccess clients use Internet Protocol security (IPsec) transport mode rules to protect the traffic from the DirectAccess client to intranet resource servers. In the case of the selected server access model, the end-to-end protection is between DirectAccess clients and a set of resource servers defined by security group membership. In the case of the end-to-end access model, the end-to-end protection is between DirectAccess clients and all intranet resource servers that are domain members.

Selected server access model

For selected server access, the DirectAccess Setup Wizard configures a compatible set of connection security rules for DirectAccess clients and the selected servers that should result in a successful establishment of transport mode IPsec security associations (SAs). If the DirectAccess client cannot successfully create the transport mode SAs, the DirectAccess client cannot connect to the selected servers on the intranet.

To verify whether the DirectAccess client can successfully create transport mode IPsec SAs to selected servers

  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 a rule named DirectAccess Policy-clientToAppServer.

  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. Double-click the DirectAccess Policy- clientToAppServer rule and then click the Computers tab. Verify that the Internet Protocol version 6 (IPv6) addresses of the selected servers are listed in Endpoint 2. This list of IPv6 addresses was configured based on the selected server security groups specified in step 4 of the DirectAccess Setup Wizard.

  7. Initiate communication with the selected server. For example, use the appropriate application or the **net view \\**SelectedServerName command.

  8. 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 of the selected server. The main mode SA should also have ComputerCert or ComputerKerb for Auth1 and UserKerb for Auth2.

  9. 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 of the selected server.

If the DirectAccess client computer cannot establish the main and quick mode SAs to the selected server using the default connection security rules created by the DirectAccess Setup Wizard, the most likely problem is the lack of corresponding connection security rules on the selected server. Verify that a rule named DirectAccess Policy-appServerToClient appears in the Connection Security Rules and Monitoring\Connection Security Rules nodes in the console tree of the Windows Firewall with Advanced Security snap-in on the selected server.

End-to-end access model

For end-to-end access, you manually configure the settings created by the DirectAccess Setup Wizard for selected server access to apply to all of the computers in your domain. For more information, see Checklist: Implementing a DirectAccess Design for End-to-End Access. The result is a compatible set of connection security rules for DirectAccess clients and all intranet domain member computers for successful negotiation of end-to-end, encrypted transport mode IPsec SAs. If the DirectAccess client cannot successfully create the transport mode SAs, the DirectAccess client cannot connect to intranet resources.

To verify whether the DirectAccess client can successfully create transport mode IPsec SAs to intranet resources

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

  2. 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 or Windows 7 Enterprise Edition 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 a rule named DirectAccess Policy-clientToAppServer.

  5. If you do not see this rule, 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. Initiate communication with an intranet server. For example, use an appropriate client application or the **net view \\**IntranetServer command.

  7. 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 of the intranet server. The main mode SA should also have ComputerCert or ComputerKerb for Auth1 and UserKerb for Auth2.

  8. 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 of the intranet server.

If the DirectAccess client computer cannot establish the main and quick mode SAs to intranet server using the modified connection security rules, the most likely problem is the lack of corresponding connection security rules on intranet servers. Verify that a rule named DirectAccess Policy-appServerToClient appears in the Connection Security Rules and Monitoring\Connection Security Rules nodes in the console tree of the Windows Firewall with Advanced Security snap-in on your intranet servers.