Download.microsoft.com



[pic]

[pic]

Test Lab Guide: Troubleshoot DirectAccess

Microsoft Corporation

Published: January 2010

Updated: July 2010

Abstract

DirectAccess is a new feature in the Windows® 7 and Windows Server® 2008 R2 operating systems that enables remote users to securely access intranet shared folders, Web sites, and applications without connecting to a virtual private network (VPN). This document is a companion to the Test Lab Guide: Demonstrate DirectAccess and describes DirectAccess troubleshooting tools, the results of the tools in a working DirectAccess test lab, and how to troubleshoot common problems in the DirectAccess test lab.

[pic]

Copyright Information

This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results from the use of this document remains with the user. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2010 Microsoft Corporation. All rights reserved.

Date of last update: July 27, 2010

Microsoft, Windows, Active Directory, Internet Explorer, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.

Contents

Introduction 5

In this guide 5

DirectAccess Troubleshooting Tools 7

DirectAccess Troubleshooting Tools in the Test Lab 11

Intranet subnet 11

netsh dnsclient show state 11

netsh namespace show policy 12

netsh namespace show effectivepolicy 12

netsh advfirewall monitor show currentprofile 13

Windows Firewall with Advanced Security snap-in 13

netsh interface isatap show state 13

netsh interface isatap show router 14

ipconfig /all 14

Internet subnet 15

netsh dnsclient show state 16

netsh namespace show effectivepolicy 16

netsh advfirewall monitor show currentprofile 17

Windows Firewall with Advanced Security snap-in 17

netsh interface 6to4 show state 18

netsh interface 6to4 show relay 19

ipconfig /all 19

Homenet subnet with Teredo connectivity 21

netsh advfirewall monitor show currentprofile 21

netsh interface teredo show state 21

ipconfig /all 21

Homenet subnet with IP-HTTPS connectivity 23

netsh interface httpstunnel show interfaces 23

ipconfig /all 23

Troubleshooting DirectAccess Client Connectivity Problems 25

Cannot resolve intranet FQDNs (root cause 1) 25

Break the configuration procedure 25

Step-by-step troubleshooting 26

Correct the configuration procedure 27

Cannot resolve intranet FQDNs (root cause 2) 28

Break the configuration procedure 28

Step-by-step troubleshooting 28

Correct the configuration procedure 30

Cannot access a specific intranet resource 30

Break the configuration procedure 30

Step-by-step troubleshooting 31

Correct the configuration procedure 31

DirectAccess client cannot correctly detect the intranet 32

Break the configuration procedure 32

Step-by-step troubleshooting 33

Correct the configuration procedure 34

DirectAccess client cannot complete an IP-HTTPS-based connection 35

Break the configuration procedure 35

Step-by-step troubleshooting 35

Correct the configuration procedure 37

Additional Resources 37

Introduction

DirectAccess is a new feature in the Windows® 7 and Windows Server® 2008 R2 operating systems that gives users the experience of being seamlessly connected to their intranet any time they have Internet access. With DirectAccess enabled, requests for intranet resources (such as e-mail servers, shared folders, or intranet Web sites) are securely directed to the intranet, without requiring users to connect to a VPN. DirectAccess provides increased productivity for a mobile workforce by offering the same connectivity experience both inside and outside the office.

In this guide

The DirectAccess test lab, as described in the Test Lab Guide: Demonstrate DirectAccess, contains four server computers running Windows Server 2008 R2 Enterprise Edition and two client computers running Windows 7 Ultimate Edition. The lab simulates an intranet, the Internet, and a home network and demonstrates DirectAccess in different Internet connection scenarios.

The DirectAccess test lab consists of:

• One computer running Windows Server 2008 R2 Enterprise Edition named DC1 that is configured as an intranet domain controller, Domain Name System (DNS) server, Dynamic Host Configuration Protocol (DHCP) server, and an enterprise root certification authority (CA).

• One intranet member server running Windows Server 2008 R2 Enterprise Edition named EDGE1 that is configured as the DirectAccess server.

• One intranet member server running Windows Server 2008 R2 Enterprise Edition named APP1 that is configured as a general application server and network location server.

• One standalone server running Windows Server 2008 R2 Enterprise Edition named INET1 that is configured as an Internet DNS and Web server.

• One standalone client computer running Windows 7 Ultimate Edition named NAT1 that is configured as a network address translator (NAT) device using Internet Connection Sharing.

• One roaming member client computer running Windows 7 Ultimate Edition named CLIENT1 that is configured as a DirectAccess client.

The DirectAccess test lab consists of three subnets that simulate the following:

• The Internet (131.107.0.0/24).

• A home network named Homenet (192.168.137.0/24) connected to the Internet by a NAT.

• An intranet named Corpnet (10.0.0.0/24) separated from the Internet by the DirectAccess server.

Computers on each subnet connect using a hub or switch. See the following figure.

[pic]

In the DirectAccess test lab, you connect CLIENT1 initially to the Corpnet subnet and join the intranet domain. After configuring EDGE1 as a DirectAccess server, you update CLIENT1 with the associated Group Policy settings. Then, you connect CLIENT1 to the Internet subnet and the Homenet subnet and test DirectAccess connectivity to intranet resources on the Corpnet subnet.

This guide uses the working DirectAccess test lab as a basis for describing DirectAccess troubleshooting tools and their results when the DirectAccess client is connected to the three different test lab subnets. This guide then takes you through various troubleshooting scenarios using topics in the DirectAccess Troubleshooting Guide and the troubleshooting tools to discover the root cause of the problem.

[pic]Important

This guide does not describe how to troubleshoot a non-functioning DirectAccess test lab. For general troubleshooting information, see the DirectAccess Troubleshooting Guide.

DirectAccess Troubleshooting Tools

Windows 7 and Windows Server 2008 R2 provide many tools for gathering information for DirectAccess problem determination and resolution. The following table lists the tools and describes their use and purpose for DirectAccess. For additional information, see Tools for Troubleshooting DirectAccess.

|Tool |Description |

|Windows Network Diagnostics |To access Windows Network Diagnostics, right-click the network |

| |connection icon in the notification area, and then click |

| |Troubleshoot problems |

| |Windows Network Diagnostics has extensive support for |

| |DirectAccess connections and in many cases provides the user with|

| |information about the root cause of the problem. |

|Troubleshooting item in Control Panel |To focus troubleshooting on DirectAccess and collect additional |

| |information, you can use the Connection to a Workplace Using |

| |DirectAccess troubleshooter in the Troubleshooting item of |

| |Control Panel. |

|Network and Windows Firewall tracing |For performing detailed troubleshooting for networking problems, |

| |network and Windows Firewall tracing provides information about |

| |internal Windows component interaction. For more information, see|

| |Network Diagnostics and Tracing. |

|netsh dnsclient show state command |Displays DNS client settings. |

| |Use this command to determine the DirectAccess client’s location |

| |and whether DirectAccess Name Resolution Policy Table (NRPT) |

| |rules have been configured and are active. |

|netsh namespace show policy command |Displays the rules in the NRPT as configured with Group Policy. |

| |Use this command to ensure that the DirectAccess client has |

| |received the NRPT rules from Group Policy. |

|netsh namespace show effectivepolicy command |Displays the active rules in the NRPT. |

| |Use this command to show whether the DirectAccess client has |

| |determined that it is on the Internet (DirectAccess NRPT rules |

| |are present) or the intranet (DirectAccess NRPT rules are not |

| |present). |

|netsh advfirewall monitor show currentprofile command |Displays the current networks and the Windows Firewall profiles |

| |to which they are assigned. |

| |Use this command to determine whether the DirectAccess client |

| |should be using connection security rules to access the intranet |

| |through the DirectAccess server when only private and public |

| |profiles are detected. |

|netsh interface isatap show state command |Displays the current state of the Intra-Site Automatic Tunnel |

| |Addressing Protocol (ISATAP) component. |

| |Use this command to determine if ISATAP component has been |

| |disabled. |

|netsh interface isatap show router command |Displays the current ISATAP router configuration. |

| |Use this command to display how the DirectAccess client is |

| |discovering the ISATAP router. |

|netsh interface teredo show state command |Displays the current state of the Teredo client component. |

| |Use this command to determine the name or address of the Teredo |

| |server and if the Teredo client component has been disabled. |

|netsh interface 6to4 show state command |Displays the current state of the 6to4 component. |

| |Use this command to determine if the 6to4 component has been |

| |disabled. |

|netsh interface 6to4 show relay command |Displays the configuration settings of the 6to4 relay. |

| |Use this command to determine the address or name that the 6to4 |

| |component of the DirectAccess client is using for the 6to4 relay.|

|netsh interface httpstunnel show interfaces command |Displays the settings and state of the Internet Protocol over |

| |Secure Hypertext Transfer Protocol (IP-HTTPS) component. |

| |Use this command to determine the current state of the IP-HTTPS |

| |component, any error conditions, and the IP-HTTPS uniform |

| |resource locator (URL). |

|ipconfig /all command |Displays the current TCP/IP configuration, including Internet |

| |Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) |

| |addresses and settings. |

| |Use this command to determine which interfaces have been |

| |configured with global IPv6 addresses. |

|nslookup -q=aaaa IntranetFQDN IntranetDNSServerIPv6Address |Simulates the DNS queries of DirectAccess clients. |

|command |Use this command to simulate the behavior of the DirectAccess |

| |client when the DirectAccess-based NRPT rules are active. |

| |Nslookup.exe does not use the NRPT. If you do not specify the |

| |IPv6 address of the intranet DNS server, Nslookup.exe will send |

| |its queries to interface-configured DNS servers. |

|nltest /dsgetdc: /force command |Displays information about Active Directory Domain Services (AD |

| |DS). |

| |Use this command to determine whether DirectAccess clients, |

| |DirectAccess servers, and intranet resources can locate and |

| |contact domain controllers for Internet Protocol security (IPsec)|

| |authentication. |

|Windows Firewall with Advanced Security snap-in |The monitoring node displays current connection security rules, |

| |main mode security associations (SAs), and quick mode SAs. For |

| |more information, see Windows Firewall with Advanced Security. |

| |Use this snap-in to determine whether there are active connection|

| |security rules and IPsec SAs on a DirectAccess client. |

|Resultant Set of Policy snap-in |Displays the set of Group Policy objects (GPOs) that are applied |

| |to a computer or user. |

| |Use this snap-in to determine whether DirectAccess GPOs have been|

| |applied to DirectAccess clients or servers. |

|Event Viewer snap-in |Displays events for Windows Firewall, intranet detection, and |

| |IPsec audit events. |

| |Use this snap-in to see the details of intranet detection and |

| |IPsec negotiation issues. For more information, see Event Viewer.|

|Certificates snap-in |Displays the installed certificates and their properties. |

| |Use this snap-in to verify that the correct certificates are |

| |installed with the correct field values. For more information, |

| |see Certificates. |

DirectAccess Troubleshooting Tools in the Test Lab

This section describes the display of key troubleshooting tools when CLIENT1 is connected to the Intranet, Internet, and Homenet subnets.

Intranet subnet

When CLIENT1 is attached to the Intranet subnet, it obtains an IPv4 address configuration, including its DNS server, from DC1. As an ISATAP host, CLIENT1 also automatically configures an ISATAP address on an ISATAP interface. Because it is attached to the intranet, there should not be any active rules in the NRPT nor any active connection security rules or IPsec SAs.

The following sections use DirectAccess troubleshooting tools and commands to display the state of CLIENT1 when it is attached to the Intranet subnet.

netsh dnsclient show state

The following is the display of the netsh dnsclient show state command on CLIENT1 when it is connected to the Intranet subnet:

Name Resolution Policy Table Options

--------------------------------------------------------------------

Query Failure Behavior : Always fall back to LLMNR and NetBIOS

if the name does not exist in DNS or

if the DNS servers are unreachable

when on a private network

Query Resolution Behavior : Resolve only IPv6 addresses for names

Network Location Behavior : Let Network ID determine when Direct

Access settings are to be used

Machine Location : Inside corporate network

Direct Access Settings : Configured and Disabled

DNSSEC Settings : Not Configured

Notice the Machine Location, which indicates that CLIENT1 has determined that it is located on the intranet (Inside corporate network).

netsh namespace show policy

The following is the display of the netsh namespace show policy command on CLIENT1 when it is connected to the Intranet subnet:

DNS Name Resolution Policy Table Settings

Settings for nls.corp.

----------------------------------------------------------------------

Certification authority : DC=com, DC=contoso, DC=corp, CN=corp-D

C1-CA

DNSSEC (Validation) : disabled

DNSSEC (IPsec) : disabled

DirectAccess (DNS Servers) :

DirectAccess (IPsec) : disabled

DirectAccess (Proxy Settings) : Bypass proxy

Settings for .corp.

----------------------------------------------------------------------

Certification authority : DC=com, DC=contoso, DC=corp, CN=corp-D

C1-CA

DNSSEC (Validation) : disabled

DNSSEC (IPsec) : disabled

DirectAccess (DNS Servers) : 2002:836b:2:1:0:5efe:10.0.0.1

DirectAccess (IPsec) : disabled

DirectAccess (Proxy Settings) : Bypass proxy

Because the netsh namespace show policy command displays the NRPT rules obtained from Group Policy, its display will not change when CLIENT1 moves to the Internet and Homenet subnets.

netsh namespace show effectivepolicy

The following is the display of the netsh namespace show effectivepolicy command on CLIENT1 when it is connected to the Intranet subnet:

DNS Effective Name Resolution Policy Table Settings

Note: DirectAccess settings would be turned off when computer is inside corporate network

There should not be any active NRPT rules when CLIENT1 is connected to the Intranet subnet.

netsh advfirewall monitor show currentprofile

The following is the display of the netsh advfirewall monitor currentprofile command on CLIENT1 when it is connected to the Intranet subnet:

Domain Profile:

----------------------------------------------------------------------

corp.

Ok.

CLIENT1 has detected the domain controller for the corp. domain (DC1) and the presence of the network location server (APP1).

Windows Firewall with Advanced Security snap-in

The following is the Monitoring\Connection Security Rules node of the Windows Firewall with Advanced Security snap-in on CLIENT1 when it is connected to the Intranet subnet:

[pic]

Because the connected network (corp.) is in the domain profile and the DirectAccess connection security rules are configured for the public or private profiles, there are no active DirectAccess connection security rules.

netsh interface isatap show state

The following is the display of the netsh interface isatap show state command on CLIENT1 when it is connected to the Intranet subnet:

ISATAP State : enabled

CLIENT1 should have the ISATAP component enabled.

netsh interface isatap show router

The following is the display of the netsh interface isatap show router command on CLIENT1 when it is connected to the Intranet subnet:

Router Name : default

Use Relay : default

Resolution Interval : default

CLIENT1 should have the default settings for the ISATAP component, which means that it will attempt to locate the intranet ISATAP router by querying the name ISATAP.

ipconfig /all

The following is the display of the ipconfig /all command on CLIENT1 when it is connected to the Intranet subnet:

Windows IP Configuration

Host Name . . . . . . . . . . . . : CLIENT1

Primary Dns Suffix . . . . . . . : corp.

Node Type . . . . . . . . . . . . : Hybrid

IP Routing Enabled. . . . . . . . : No

WINS Proxy Enabled. . . . . . . . : No

DNS Suffix Search List. . . . . . : corp.

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : corp.

Description . . . . . . . . . . . : ADMtek AN983 based ethernet adapter

Physical Address. . . . . . . . . : 00-04-5A-56-0F-FF

DHCP Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

Link-local IPv6 Address . . . . . : fe80::b52f:36dc:be07:9d6d%13(Preferred)

IPv4 Address. . . . . . . . . . . : 10.0.0.100(Preferred)

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Lease Obtained. . . . . . . . . . : Tuesday, December 08, 2009 10:26:13 AM

Lease Expires . . . . . . . . . . : Wednesday, December 16, 2009 10:26:17 AM

Default Gateway . . . . . . . . . :

DHCP Server . . . . . . . . . . . : 10.0.0.1

DHCPv6 IAID . . . . . . . . . . . : 369099866

DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-15-01-C8-00-13-72-2B-34-07

DNS Servers . . . . . . . . . . . : 10.0.0.1

NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter iphttpsinterface:

Media State . . . . . . . . . . . : Media disconnected

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : iphttpsinterface

Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

DHCP Enabled. . . . . . . . . . . : No

Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Teredo Tunneling Pseudo-Interface:

Media State . . . . . . . . . . . : Media disconnected

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface

Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

DHCP Enabled. . . . . . . . . . . : No

Autoconfiguration Enabled . . . . : Yes

Tunnel adapter 6TO4 Adapter:

Media State . . . . . . . . . . . : Media disconnected

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Microsoft 6to4 Adapter

Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

DHCP Enabled. . . . . . . . . . . : No

Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.corp.:

Connection-specific DNS Suffix . : corp.

Description . . . . . . . . . . . : Microsoft ISATAP Adapter

Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

DHCP Enabled. . . . . . . . . . . : No

Autoconfiguration Enabled . . . . : Yes

IPv6 Address. . . . . . . . . . . : 2002:836b:2:1:0:5efe:10.0.0.100(Preferred)

Link-local IPv6 Address . . . . . : fe80::5efe:10.0.0.100%15(Preferred)

Default Gateway . . . . . . . . . : fe80::5efe:10.0.0.2%15

DNS Servers . . . . . . . . . . . : 10.0.0.1

NetBIOS over Tcpip. . . . . . . . : Disabled

Notice the IPv4 address assigned to the Local Area Connection interface (obtained from DC1, the DHCP server for the Intranet subnet), the ISATAP address assigned to the Tunnel adapter isatap.corp. interface, and the disconnected state of the Tunnel adapter iphttpsinterface, Tunnel adapter Teredo Tunneling Pseudo-Interface, and Tunnel adapter 6TO4 Adapter interfaces.

Internet subnet

When CLIENT1 is attached to the Internet subnet, it obtains an IPv4 address configuration, including its DNS server, from INET1. As a 6to4 host, CLIENT1 also automatically configures a 6to4 address on a 6to4 tunneling interface. Because it is no longer attached to the intranet, there should be active rules in the NRPT and active connection security rules and IPsec SAs.

netsh dnsclient show state

The following is the display of the netsh dnsclient show state command on CLIENT1 when it is connected to the Internet subnet:

Name Resolution Policy Table Options

--------------------------------------------------------------------

Query Failure Behavior : Always fall back to LLMNR and NetBIOS

if the name does not exist in DNS or

if the DNS servers are unreachable

when on a private network

Query Resolution Behavior : Resolve only IPv6 addresses for names

Network Location Behavior : Let Network ID determine when Direct

Access settings are to be used

Machine Location : Outside corporate network

Direct Access Settings : Configured and Enabled

DNSSEC Settings : Not Configured

Notice the Machine Location, which indicates that CLIENT1 has determined that it is not on the intranet (Outside corporate network). The display of this command will not change when CLIENT1 moves to the Homenet subnet.

netsh namespace show effectivepolicy

The following is the display of the netsh namespace show effectivepolicy command on CLIENT1 when it is connected to the Internet subnet:

DNS Effective Name Resolution Policy Table Settings

Settings for nls.corp.

----------------------------------------------------------------------

Certification authority : DC=com, DC=contoso, DC=corp, CN=corp-D

C1-CA

DNSSEC (Validation) : disabled

IPsec settings : disabled

DirectAccess (DNS Servers) :

DirectAccess (Proxy Settings) : Bypass proxy

Settings for .corp.

----------------------------------------------------------------------

Certification authority : DC=com, DC=contoso, DC=corp, CN=corp-D

C1-CA

DNSSEC (Validation) : disabled

IPsec settings : disabled

DirectAccess (DNS Servers) : 2002:836b:2:1:0:5efe:10.0.0.1

DirectAccess (Proxy Settings) : Bypass proxy

Because CLIENT1 cannot access network location URL , it does not remove the two DirectAccess rules from the active NRPT.

netsh advfirewall monitor show currentprofile

The following is the display of the netsh advfirewall monitor show currentprofile command on CLIENT1 when it is connected to the Internet subnet:

Public Profile:

----------------------------------------------------------------------

Unidentified network

Ok.

CLIENT1 has not detected the domain controller for the corp. domain (DC1) and the presence of the network location server (APP1) on the Internet subnet.

Windows Firewall with Advanced Security snap-in

The following is the Monitoring\Connection Security Rules node of the Windows Firewall with Advanced Security snap-in on CLIENT1 when it is connected to the Internet subnet:

[pic]

The following is the Monitoring\Security Associations\Main Mode node of the Windows Firewall with Advanced Security snap-in on CLIENT1 when it is connected to the Internet subnet:

[pic]

The following is the Monitoring\Security Associations\Quick Mode node of the Windows Firewall with Advanced Security snap-in on CLIENT1 when it is connected to the Internet subnet:

[pic]

Because the connected network (Unidentified network) is in the public profile and the DirectAccess connection security rules are configured for the public or private profiles, there are active DirectAccess connection security rules and both main mode and quick mode SAs.

Note Quick mode IPsec SAs can time-out and be automatically removed. To reinitialize them, run the net view \\app1 command on CLIENT1 and refresh the list of quick mode SAs with the F5 key.

netsh interface 6to4 show state

The following is the display of the netsh interface 6to4 show state command on CLIENT1 when it is connected to the Internet subnet:

6to4 Service State : enabled

Undo on Service Stop : default

netsh interface 6to4 show relay

The following is the display of the netsh interface 6to4 show relay command on CLIENT1 when it is connected to the Internet subnet:

Relay Name : 131.107.0.2 (Group Policy)

Use Relay : default

Resolution Interval : default

The 6to4 component on CLIENT1 is configured through Group Policy to use the 6to4 relay at 131.107.0.2 (EDGE1).

ipconfig /all

The following is the display of the ipconfig /all command on CLIENT1 when it is connected to the Internet subnet:

Windows IP Configuration

Host Name . . . . . . . . . . . . : CLIENT1

Primary Dns Suffix . . . . . . . : corp.

Node Type . . . . . . . . . . . . : Hybrid

IP Routing Enabled. . . . . . . . : No

WINS Proxy Enabled. . . . . . . . : No

DNS Suffix Search List. . . . . . : corp.

Ethernet adapter Local Area Connection 2:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : ADMtek AN983 based ethernet adapter

Physical Address. . . . . . . . . : 00-04-5A-56-0F-FF

DHCP Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

Link-local IPv6 Address . . . . . : fe80::b52f:36dc:be07:9d6d%13(Preferred)

IPv4 Address. . . . . . . . . . . : 131.107.0.101(Preferred)

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 131.107.0.1

DHCPv6 IAID . . . . . . . . . . . : 369099866

DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-15-01-C8-00-13-72-2B-34-07

DNS Servers . . . . . . . . . . . : 131.107.0.1

NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter iphttpsinterface:

Media State . . . . . . . . . . . : Media disconnected

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : iphttpsinterface

Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

DHCP Enabled. . . . . . . . . . . : No

Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Teredo Tunneling Pseudo-Interface:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface

Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

DHCP Enabled. . . . . . . . . . . : No

Autoconfiguration Enabled . . . . : Yes

IPv6 Address. . . . . . . . . . . : 2001:0:836b:2:2cf5:245:7c94:ff9a(Preferred)

Link-local IPv6 Address . . . . . : fe80::2cf5:245:7c94:ff9a%14(Preferred)

Default Gateway . . . . . . . . . :

NetBIOS over Tcpip. . . . . . . . : Disabled

Tunnel adapter 6TO4 Adapter:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Microsoft 6to4 Adapter

Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

DHCP Enabled. . . . . . . . . . . : No

Autoconfiguration Enabled . . . . : Yes

IPv6 Address. . . . . . . . . . . : 2002:836b:65::836b:65(Preferred)

Default Gateway . . . . . . . . . : 2002:836b:2::836b:2

DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1

fec0:0:0:ffff::2%1

fec0:0:0:ffff::3%1

NetBIOS over Tcpip. . . . . . . . : Disabled

Tunnel adapter isatap.{04076670-7AF6-4B18-BF7E-8CB8393C4B4D}:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Microsoft ISATAP Adapter

Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

DHCP Enabled. . . . . . . . . . . : No

Autoconfiguration Enabled . . . . : Yes

Link-local IPv6 Address . . . . . : fe80::200:5efe:131.107.0.101%15(Preferred

)

Default Gateway . . . . . . . . . :

DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1

fec0:0:0:ffff::2%1

fec0:0:0:ffff::3%1

NetBIOS over Tcpip. . . . . . . . : Disabled

Notice the IPv4 address assigned to the Local Area Connection interface (from INET1), the 6to4 address and default gateway assigned to the Tunnel adapter 6TO4 Adapter interface, the Teredo address assigned to the Tunnel adapter Teredo Tunneling Pseudo-Interface, and the disconnected state of the Tunnel adapter iphttpsinterface interface.

Homenet subnet with Teredo connectivity

When CLIENT1 is attached to the Homenet subnet, it obtains an IPv4 address configuration, including its DNS server, from NAT1. Because CLIENT1 does not have a public IPv4 address, it cannot use 6to4. As a Teredo client, CLIENT1 automatically configures a Teredo address on a Teredo tunneling interface.

netsh advfirewall monitor show currentprofile

The following is the display of the netsh advfirewall monitor show currentprofile command on CLIENT1 when it is connected to the Homenet subnet:

Private Profile:

----------------------------------------------------------------------

Unidentified network

Ok.

CLIENT1 has been assigned a private IPv4 address and has not detected the domain controller for the corp. domain (DC1) and the presence of the network location server (APP1) on the Homenet subnet.

netsh interface teredo show state

The following is the display of the netsh interface teredo show state command on CLIENT1 when it is connected to the Homenet subnet:

Teredo Parameters

---------------------------------------------

Type : enterpriseclient

Server Name : 131.107.0.2 (Group Policy)

Client Refresh Interval : 30 seconds

Client Port : unspecified

State : qualified

Client Type : teredo client

Network : managed

NAT : restricted

NAT Special Behaviour : UPNP: No, PortPreserving: Yes

Local Mapping : 192.168.137.65:60151

External NAT Mapping : 131.107.0.100:60151

ipconfig /all

The following is the display of the ipconfig /all command on CLIENT1 when it is connected to the Homenet subnet:

Windows IP Configuration

Host Name . . . . . . . . . . . . : CLIENT1

Primary Dns Suffix . . . . . . . : corp.

Node Type . . . . . . . . . . . . : Hybrid

IP Routing Enabled. . . . . . . . : No

WINS Proxy Enabled. . . . . . . . : No

DNS Suffix Search List. . . . . . : corp.

Ethernet adapter Local Area Connection 2:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : ADMtek AN983 based ethernet adapter

Physical Address. . . . . . . . . : 00-04-5A-56-0F-FF

DHCP Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

Link-local IPv6 Address . . . . . : fe80::b52f:36dc:be07:9d6d%13(Preferred)

IPv4 Address. . . . . . . . . . . : 192.168.137.0.17(Preferred)

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 192.168.137.1

DHCPv6 IAID . . . . . . . . . . . : 369099866

DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-15-01-C8-00-13-72-2B-34-07

DNS Servers . . . . . . . . . . . : 192.168.137.1

NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter iphttpsinterface:

Media State . . . . . . . . . . . : Media disconnected

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : iphttpsinterface

Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

DHCP Enabled. . . . . . . . . . . : No

Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Teredo Tunneling Pseudo-Interface:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface

Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

DHCP Enabled. . . . . . . . . . . : No

Autoconfiguration Enabled . . . . : Yes

IPv6 Address. . . . . . . . . . . : 2001:0:836b:2:2cf5:245:7c94:ff9a(Preferred)

Link-local IPv6 Address . . . . . : fe80::2cf5:245:7c94:ff9a%14(Preferred)

Default Gateway . . . . . . . . . : ::

NetBIOS over Tcpip. . . . . . . . : Disabled

Tunnel adapter 6TO4 Adapter:

Media State . . . . . . . . . . . : Media disconnected

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Microsoft 6to4 Adapter

Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

DHCP Enabled. . . . . . . . . . . : No

Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.{04076670-7AF6-4B18-BF7E-8CB8393C4B4D}:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Microsoft ISATAP Adapter

Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

DHCP Enabled. . . . . . . . . . . : No

Autoconfiguration Enabled . . . . : Yes

Link-local IPv6 Address . . . . . : fe80::200:5efe:131.107.0.101%15(Preferred)

Default Gateway . . . . . . . . . :

DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1

fec0:0:0:ffff::2%1

fec0:0:0:ffff::3%1

NetBIOS over Tcpip. . . . . . . . : Disabled

Notice the IPv4 address assigned to the Local Area Connection interface (from NAT1), the Teredo address assigned to the Tunnel adapter Teredo Tunneling Pseudo-Interface, and the disconnected state of the Tunnel adapter 6TO4 Adapter and Tunnel adapter iphttpsinterface interfaces.

Homenet subnet with IP-HTTPS connectivity

When CLIENT1 is attached to the Homenet subnet and you disable the Teredo client component with the netsh interface teredo set state disabled command, CLIENT1 attempts to configure an IPv6 address on an IP-HTTPS tunneling interface.

netsh interface httpstunnel show interfaces

The following is the display of the netsh interface httpstunnel show interfaces command on CLIENT1 when it is connected to the Homenet subnet with the Teredo client disabled:

Interface IPHTTPSInterface (Group Policy) Parameters

------------------------------------------------------------

Role : client

URL :

Last Error Code : 0x0

Interface Status : IPHTTPS interface activated

ipconfig /all

The following is the display of the ipconfig /all command on CLIENT1 when it is connected to the Homenet subnet with the Teredo client disabled:

Windows IP Configuration

Host Name . . . . . . . . . . . . : CLIENT1

Primary Dns Suffix . . . . . . . : corp.

Node Type . . . . . . . . . . . . : Hybrid

IP Routing Enabled. . . . . . . . : No

WINS Proxy Enabled. . . . . . . . : No

DNS Suffix Search List. . . . . . : corp.

Ethernet adapter Local Area Connection 2:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : ADMtek AN983 based ethernet adapter

Physical Address. . . . . . . . . : 00-04-5A-56-0F-FF

DHCP Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

Link-local IPv6 Address . . . . . : fe80::b52f:36dc:be07:9d6d%13(Preferred)

IPv4 Address. . . . . . . . . . . : 192.168.137.0.17(Preferred)

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 192.168.137.1

DHCPv6 IAID . . . . . . . . . . . : 369099866

DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-15-01-C8-00-13-72-2B-34-07

DNS Servers . . . . . . . . . . . : 192.168.137.1

NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter iphttpsinterface:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : iphttpsinterface

Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

DHCP Enabled. . . . . . . . . . . : No

Autoconfiguration Enabled . . . . : Yes

IPv6 Address. . . . . . . . . . . : 2002:836b:2:2:31af:219a:957c:21ad(Preferred)

Link-local IPv6 Address . . . . . : fe80::31af:219a:957c:21ad%16(Preferred)

Default Gateway . . . . . . . . . : fe80::6d5c:17f7:69e8:dd2b

NetBIOS over Tcpip. . . . . . . . : Disabled

Tunnel adapter isatap.{04076670-7AF6-4B18-BF7E-8CB8393C4B4D}:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : Microsoft ISATAP Adapter

Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

DHCP Enabled. . . . . . . . . . . : No

Autoconfiguration Enabled . . . . : Yes

Link-local IPv6 Address . . . . . : fe80::200:5efe:131.107.0.101%15(Preferred)

Default Gateway . . . . . . . . . :

DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1

fec0:0:0:ffff::2%1

fec0:0:0:ffff::3%1

NetBIOS over Tcpip. . . . . . . . : Disabled

Notice the global address assigned to the Tunnel adapter iphttpsinterface.

Troubleshooting DirectAccess Client Connectivity Problems

The following sections contain troubleshooting scenarios in which you deliberately configure the DirectAccess test lab to impair DirectAccess connectivity. You will then use the troubleshooting techniques described in the DirectAccess Troubleshooting Guide and the troubleshooting tools described in this document to determine the root cause of the problem and correct it.

Cannot resolve intranet FQDNs (root cause 1)

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.

[pic]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. The following procedure uses the appropriate steps in DirectAccess Client Cannot Resolve Names with Intranet DNS Servers and DirectAccess Client Cannot Establish Tunnels to the DirectAccess Server to determine the root cause of the problem.

[pic]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. NRPT rule. |

|3. From the Command Prompt window, use the nslookup -q=aaaa IntranetFQDN IntranetDNSServerIPv6Address command to resolve |

|the fully qualified domain name (FQDN) for APP1 (app1.corp.). |

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

|4. Click Start, type wf.msc, and then press ENTER. |

|5. In the console tree, open Monitoring/Security Associations/Main Mode and Monitoring/Security Associations/Quick Mode. |

|There should be no IPsec SAs. |

|6. From the Command Prompt window, run the netsh advfirewall monitor show currentprofile command. This should display the |

|Unidentified network in the public profile. |

|7. On DC1, run an administrator-level Command Prompt. |

|8. In the Command Prompt window, run the netsh –c advfirewall command. |

|9. From the netsh advfirewall prompt, run the set store gpo="corp.\DirectAccess |

|Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}" command. |

|10. From the netsh advfirewall prompt, run the consec show rule name="DirectAccess Policy-ClientToDnsDc" command. Note the|

|value of Auth1CAName. |

|11. From the netsh advfirewall prompt, run the exit command. |

|12. From the Certificates (Local Computer)\Personal\Certificates node of the Certificates snap-in, obtain properties of |

|the EDGE1.corp. 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.

[pic]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. |

Cannot resolve intranet FQDNs (root cause 2)

By default, DC1 listens to incoming DNS messages on all of its assigned IPv4 and IPv6 addresses, including the ISATAP address of DC1. CLIENT1 has been configured with the namespace NRPT rule for the corp. domain and to send the DNS queries matching that namespace to the ISATAP address of DC1.

In this troubleshooting scenario, you will configure the DNS Server service on DC1 to not respond to DNS messages destined to its ISATAP address and then troubleshoot the results.

Break the configuration procedure

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

[pic]To configure DC1 to ignore DNS messages sent to its ISATAP address

|1. Connect CLIENT1 to the Internet subnet. Verify that CLIENT1 can run the net view \\app1 command. |

|2. On DC1, run the DNS snap-in. Right-click DC1 in the console tree, and then click Properties. |

|3. On the Interfaces tab, click Only the following IP addresses, clear the check box for 2002:836b:2:1:0:5efe:10.0.0.1, |

|and then click OK. |

|4. On CLIENT1, from the Command Prompt window, run the ipconfig /flushdns command. |

|5. 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. The following procedure uses the appropriate steps in DirectAccess Client Cannot Resolve Names with Intranet DNS Servers and DirectAccess Client Cannot Establish Tunnels to the DirectAccess Server to determine the root cause of the problem.

[pic]To troubleshoot this scenario

|1. On CLIENT1, from the Command Prompt window, run the netsh namespace show effective command. You should see the two NRPT|

|rules. |

|2. From the Command Prompt window, ping the IPv6 address listed in the .corp. NRPT rule. |

|3. From the Command Prompt window, use the nslookup -q=aaaa IntranetFQDN IntranetDNSServerIPv6Address command to resolve |

|the FQDN for APP1. |

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

|4. Click Start, type wf.msc, and then press ENTER. |

|5. In the console tree, open Monitoring/Security Associations/Main Mode and Monitoring/Security Associations/Quick Mode. |

|There should be both main mode and quick mode IPsec SAs. |

|Since the problem is not with IPsec SAs, let’s return to the connectivity between CLIENT1 and DC1. |

|6. From the Command Prompt window, use the net view \\IntranetDNSServerIPv6Address command to attempt to connect to DC1. |

|This command should be successful, indicating that DC1 is processing file sharing traffic, but not DNS traffic. |

|7. On APP1, run an administrator-level Command Prompt. |

|8. From the Command Prompt window, run the ipconfig /all command. Notice that APP1 is configured to use 10.0.0.1 as its |

|DNS server. This is the IPv4 address of DC1. |

|9. From the Command Prompt window, run the ipconfig /flushdns command. |

|10. From the Command Prompt window, run the nslookup isatap.corp. 10.0.0.1 command. This command should be |

|successful. |

|11. From the Command Prompt window, run the ipconfig /flushdns command. |

|12. From the Command Prompt window, run the nslookup isatap.corp. 2002:836b:2:10:5efe:10.0.0.1 command. This |

|command should not be successful. |

|This step demonstrates that the DNS Server service on DC1 is operating and processing requests destined to its IPv4 |

|address of 10.0.0.1, but not its ISATAP address of 2002:836b:2:10:5efe:10.0.0.1. This condition indicates an issue with |

|the interface configuration of the DNS Server service on DC1. |

|13. On DC1, run the DNS snap-in. In the console tree, right-click DC1, and then click Properties. |

|14. On the Interfaces tab, note that the ISATAP address is not enabled. |

This is the root cause of the problem. The DNS Server is not bound to and listening for incoming DNS messages sent to its ISATAP address. Because DirectAccess clients send their DNS messages to the ISATAP address of DC1, this configuration disables intranet DNS name resolution for DirectAccess clients that are on the Internet.

Correct the configuration procedure

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

[pic]To configure DC1 to process DNS messages sent to all of its addresses

|1. On DC1, run the DNS snap-in. In the console tree, right-click DC1, and then click Properties. |

|2. On the Interfaces tab, click All IP addresses, and then click OK. |

|3. In the console tree, right-click DC1, point to All Tasks, and then click Restart. |

|4. On CLIENT1, from the Command Prompt window, run the ping app1 command. This should be successful. |

Cannot access a specific intranet resource

For the DirectAccess test lab, intranet resources must be configured with reachable IPv6 addresses to be accessible by CLIENT1 when connected to the Internet or Homenet subnets. In some cases, network administrators disable IPv6 functionality on client or server computers on their intranets with the DisabledComponents registry value.

In this troubleshooting scenario, you configure the DisabledComponents registry value on the APP1 server to disable IPv6 functionality and then troubleshoot the results.

Break the configuration procedure

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

[pic]To disable IPv6 functionality on APP1

|1. On APP1, run an administrator-level command prompt. |

|2. From the Command Prompt window, run the reg add HKLM\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters /v |

|DisabledComponents /t REG_DWORD /d 0xFF command. |

|3. Restart APP1. |

|4. Connect CLIENT1 to the Internet subnet. |

|5. On CLIENT1, from the Command Prompt window, run the ipconfig /flushdns command. |

|6. On CLIENT1, 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 Corpnet DNS server, is not resolving the intranet name for APP1. The following procedure uses the appropriate steps in DirectAccess Client Cannot Resolve Names with Intranet DNS Servers and DirectAccess Client Cannot Access Intranet Resources to determine the root cause of the problem.

[pic]To troubleshoot this scenario

|1. On CLIENT1, from the Command Prompt window, run the netsh namespace show effective command. You should see the two NRPT|

|rules. |

|2. From the Command Prompt window, ping the IPv6 address listed in the .corp. NRPT rule. |

|3. From the Command Prompt window, use the nslookup -q=aaaa IntranetFQDN IntranetDNSServerIPv6Address command to resolve |

|the FQDN for APP1. |

|Nslookup does not return an IPv6 address for the name app1.corp.. |

|4. On APP1, run an administrator-level command prompt. |

|5. From the Command Prompt window, run the reg query HKLM\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters /v |

|DisabledComponents command. |

|Notice that the DisabledComponents registry value is set to 0xFF, which disables IPv6 functionality. |

This is the root cause of the problem. Without IPv6 functionality, APP1 is not reachable by DirectAccess clients.

Correct the configuration procedure

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

[pic]To enable IPv6 functionality on APP1

|1. On APP1, run an administrator-level command prompt. |

|2. From the Command Prompt window, run the reg delete HKLM\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters /v |

|DisabledComponents /f command. |

|3. Restart APP1. |

|4. On CLIENT1, from the Command Prompt window, run the ipconfig /flushdns command. |

|5. From the Command Prompt window, run the ping app1 command. This should be successful. |

DirectAccess client cannot correctly detect the intranet

When connecting to any network, a DirectAccess client attempts to access its network location server, a Web server that is only available on the intranet. If a DirectAccess client cannot successfully access the network location server when connected to its intranet, depending on its configuration, it cannot resolve intranet DNS names.

In this troubleshooting scenario, you configure the SSL binding on the network location server (APP1) to use the wrong certificate and then troubleshoot the results.

Break the configuration procedure

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

[pic]To configure IIS on APP1 to use the wrong SSL certificate

|1. On APP1, click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager. |

|2. In the console tree, open APP1\Sites, and then click Default Web Site. |

|3. In Actions, click Bindings. |

|4. In Site Bindings, click https, and then click Edit. |

|5. In Edit Site Binding, in SSL certificate, click APP1.corp., and then click OK. When prompted by two Edit |

|Site Binding messages, click Yes for both. |

|6. Connect CLIENT1 to the intranet subnet. |

|7. From the Command Prompt window, run the ping app1 command. This command should display the Ping request could not find |

|host app1 message. |

|8. From the Command Prompt window, run the ipconfig command. Notice that there are no global IPv6 addresses assigned. |

|CLIENT1 cannot resolve the name ISATAP to reach the intranet ISATAP server and configure the Tunnel adapter |

|isatap.corp. interface. |

Step-by-step troubleshooting

From the previous procedure, it appears that DC1, the intranet DNS server, is not resolving intranet names for CLIENT1 even when it is directly attached to the intranet. The following procedure uses the appropriate steps in DirectAccess Client Determines that it is on the Internet When on the Intranet to determine the root cause of the problem.

[pic]To troubleshoot this scenario

|1. On CLIENT1, from the Command Prompt window, run the netsh namespace show effective command. If intranet detection was |

|successful you would not see the two NRPT rules. However, because intranet detection was not successful, you should see |

|the two NRPT rules. |

|2. From the Command Prompt window, run the reg query |

|HKLM\software\policies\microsoft\windows\NetworkConnectivityStatusIndicator\CorporateConnectivity /v |

|DomainLocationDeterminationUrl command. This command displays the network location URL. |

|3. From the display of the netsh namespace show effective command in step 1, verify that the FQDN in the network location |

|URL appears as an exemption rule in the NRPT (nls.corp.). |

|4. From the Command Prompt window, ping the FQDN in the network location URL. This command should be successful. |

|5. Open Internet Explorer, type the network location URL in the address bar, and press ENTER. |

|You should see a “There is a problem with this website’s security certificate.” message. This indicates that CLIENT1 could|

|not perform a successful validation of the SSL certificate used by APP1 for HTTPS-based URLs. |

|6. On APP1, run the Internet Information Services (IIS) Manager snap-in. |

|7. In the console tree, open APP1\Sites, and then click NLS. |

|8. In Actions, click Bindings. |

|9. In Site Bindings, click https, and then click Edit. |

|10. In Edit Site Binding, in SSL certificate, notice the name of the selected certificate. |

|11. Click View, click the Details tab, and then click the Subject field. Notice that the Subject field FQDN |

|(APP1.corp.) does not match the FQDN from the network location URL (nls.corp.). |

This is the root cause of the problem. For SSL-based Web connections, the FQDN in the Subject field of the certificate must match the FQDN of the URL that is being used to access the Web site. Because CLIENT1 cannot successfully access the HHTPS-based network location URL, network location detection fails and CLIENT1 determines that it is connected to the Internet, rather than the intranet.

Correct the configuration procedure

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

[pic]To configure IIS on APP1 to use the correct SSL certificate

|1. On APP1, click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager. |

|2. In the console tree, open APP1\Sites, and then click NLS. |

|3. In Actions, click Bindings. |

|4. In Site Bindings, click https, and then click Edit. |

|5. In Edit Site Binding, in SSL certificate, click nls.corp., and then click OK. When prompted by two Edit |

|Site Binding messages, click Yes for both. |

|6. Disconnect CLIENT1 from the intranet subnet, wait 30 seconds, and then reconnect it to the intranet subnet. |

|7. From the Command Prompt window, run the ping app1 command. This command should be successful. |

|8. From the Command Prompt window, run the ipconfig command. Notice that there is now a global IPv6 address assigned to |

|the Tunnel adapter isatap.corp. that begins with 2002:836b:2. |

DirectAccess client cannot complete an IP-HTTPS-based connection

A DirectAccess client that is behind a Web proxy or a NAT that does not allow Teredo traffic attempts to connect to its DirectAccess server using IP-HTTPS. A DirectAccess client using IP-HTTPS attempts a validated SSL connection to the IP-HTTPS (the DirectAccess server) with certificate validation, which includes checking the certificate for revocation.

In this troubleshooting scenario, you configure the DNS A record for the FQDN of the Internet certificate revocation list (CRL) distribution point for the wrong IPv4 address and troubleshoot the results.

Break the configuration procedure

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

[pic]To configure DNS on INET1 to resolve the wrong IPv4 address for crl.

|1. On INET1, click Start, point to Administrative Tools, and then click DNS. |

|2. In the console tree, open INET1\Forward Lookup Zones\. |

|3. In the details pane, double-click the crl address record. |

|4. In IP address, type 131.107.0.9, and then click OK. |

|5. Connect CLIENT1 to the Homenet subnet and run an administrator-level command prompt. |

|6. From the Command Prompt window, run the netsh interface teredo set state disabled command. |

|7. Unplug the network adapter of CLIENT1 from the Homenet subnet, wait 30 seconds, then plug it back into the Homenet |

|subnet. |

|8. From the Command Prompt window, run the ipconfig command. Notice that there are no IPv6 addresses assigned to the |

|Tunnel adapter ip-httsinterface interface. |

Step-by-step troubleshooting

From the previous procedure, it appears that CLIENT1 cannot obtain an IP-HTTPS connection with the DirectAccess server. The following procedure uses the appropriate steps in Cannot Reach the DirectAccess Server with IP-HTTPS to determine the root cause of the problem.

[pic]To troubleshoot this scenario

|1. On CLIENT1, from the Command Prompt window, run the reg query HKLM\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters |

|/v DisabledComponents command. This command should display ERROR: The system was unable to find the specified registry key|

|or value. |

|2. From the Command Prompt window, run the netsh interface httpstunnel show interfaces command. This command displays the |

|configuration and state of the IP-HTTPS tunnel interface on CLIENT1. The Last Error Code field should display 0x800b010f. |

|3. On EDGE1, run an administrator-level Command Prompt. |

|4. From the Command Prompt window, run the netsh interface httpstunnel show interfaces command. This command displays the |

|configuration and state of the IP-HTTPS tunnel interface on EDGE1. The Interface Status field should display IPHTTPS |

|interface active. |

|5. On CLIENT1, from the Command Prompt window, ping the FQDN from the URL field in step 2. |

|6. Open Internet Explorer, type the URL from step 3 in the address bar, and press ENTER. |

|You should see a “There is a problem with this website’s security certificate.” message. This indicates that CLIENT1 could|

|not perform a successful validation of the SSL certificate used by EDGE1 for HTTPS-based URLs. |

|7. On EDGE1, from the Certificates (Local Computer)\Personal\Certificates node of the Certificates snap-in, obtain |

|properties of the EDGE1. certificate. Click the Details tab and then click the Subject field. Notice that the |

|FQDN in the Subject field is the same as the FDQN of the IP-HTTPS URL in step 2. |

|8. Click the CRL Distribution Points field and notice the URL listed at the end. |

|9. On CLIENT1, from the Command Prompt window, ping the FQDN from the URL in step 8. You should see a series of |

|Destination host unreachable error messages. You should also note that the name crl. is being resolved to |

|131.107.0.9, instead of 131.107.0.2, the IPv4 address of EDGE1 on the Internet. |

This is the root cause of the problem. Because CLIENT1 cannot successfully access the Internet CRL distribution point, the IP-HTTPS connection fails.

Note For a list of error codes for the IP-HTTPS interface, see COM Error Codes (Security and Setup).

Correct the configuration procedure

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

[pic]To configure DNS on INET1 to resolve the correct IPv4 address for crl.

|1. On INET1, click Start, point to Administrative Tools, and then click DNS. |

|2. In the console tree, open INET1\Forward Lookup Zones\. |

|3. In the details pane, double-click the crl address record. |

|4. In IP address, type 131.107.0.2, and then click OK. |

|5. Unplug the network adapter of CLIENT1 from the Homenet subnet, wait 30 seconds, then plug it back into the Homenet |

|subnet. |

|6. From the Command Prompt window, run the ipconfig command. Notice that there is now a global IPv6 address assigned to |

|the Tunnel adapter ip-httsinterface interface. |

|7. From the Command Prompt window, run the netsh interface teredo set state enabled command. |

Additional Resources

For procedures to configure the DirectAccess test lab on which this document is based, see the Test Lab Guide: Demonstrate DirectAccess.

For information about troubleshooting DirectAccess in Windows Server 2008 R2, see the DirectAccess Troubleshooting Guide.

For design and configuration of your pilot or production deployment of DirectAccess in Windows Server 2008 R2, see the DirectAccess Design Guide and the DirectAccess Deployment Guide.

For more information about DirectAccess, see the DirectAccess Solution Web page and the DirectAccess TechNet Web page.

To get your questions about DirectAccess answered, see the Network Infrastructure Servers TechNet Forum.[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download