Introductiondownload.microsoft.com/.../TestLabGuide_Troublesho… · Web viewTest Lab Guide:...

Test Lab Guide: Troubleshooting Forefront UAG DirectAccess Microsoft CorporationPublished: July 2010

AbstractDirectAccess 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). Forefront Unified Access Gateway (UAG) extends the value of DirectAccess by providing support for highly available arrays, centralized management, and support for IPv4 networks and resources. This white paper is a companion to the Test Lab Guide: Demonstrate UAG DirectAccess and describes DirectAccess troubleshooting tools, the results of the tools in a working UAG DirectAccess Test Lab, and how to troubleshoot common UAG DirectAccess problems using the Test Lab.

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

Last Updated: July 26, 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....................................................................................................................................1In this guide.................................................................................................................................1

DirectAccess Troubleshooting Tools...............................................................................................2

UAG DirectAccess Troubleshooting Tools in the Test Lab...............................................................7Corpnet Subnet...........................................................................................................................7

netsh dnsclient show state......................................................................................................7netsh namespace show policy.................................................................................................8netsh namespace show effectivepolicy....................................................................................9netsh advfirewall monitor show currentprofile.......................................................................9Windows Firewall with Advanced Security snap-in..................................................................9netsh interface isatap show state..........................................................................................10netsh interface isatap show router........................................................................................10ipconfig /all............................................................................................................................10

Internet subnet.........................................................................................................................12netsh dnsclient show state....................................................................................................12netsh namespace show effectivepolicy..................................................................................12netsh advfirewall monitor show currentprofile.....................................................................13Windows Firewall with Advanced Security snap-in................................................................13netsh interface 6to4 show state............................................................................................15netsh interface 6to4 show relay............................................................................................15ipconfig /all............................................................................................................................16

Homenet subnet with Teredo connectivity...............................................................................17netsh advfirewall monitor show currentprofile.....................................................................17netsh interface teredo show state.........................................................................................18ipconfig /all............................................................................................................................18

Homenet subnet with IP-HTTPS connectivity............................................................................19netsh interface httpstunnel show interfaces.........................................................................19ipconfig /all............................................................................................................................20

Troubleshooting DirectAccess Client Connectivity Problems.......................................................21Cannot resolve intranet FQDNs (root cause 1)..........................................................................21

Procedure to break the configuration....................................................................................21Step-by-step troubleshooting................................................................................................22Correct the configuration procedure.....................................................................................24

Cannot resolve intranet FQDNs (root cause 2)..........................................................................25Procedure to break the configuration....................................................................................25Step-by-step troubleshooting................................................................................................26

Correct the configuration procedure.....................................................................................28Cannot access the Corpnet........................................................................................................28

Procedure to break the configuration....................................................................................28Step-by-step troubleshooting................................................................................................29Correct the configuration procedure.....................................................................................32

DirectAccess client cannot correctly detect the intranet..........................................................32Procedure to break the configuration....................................................................................32Step-by-step troubleshooting................................................................................................33Correct the configuration procedure.....................................................................................34

IntroductionDirectAccess 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. Forefront Unified Access Gateway 2010 extends the value of DirectAccess by providing support for highly available arrays, centralized management, and support for IPv4 networks and resources. 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 or an application gateway. DirectAccess provides increased productivity for a mobile workforce by offering the same connectivity experience both inside and outside the office.

In this guideThe lab simulates an intranet, the Internet, and a home network and demonstrates UAG DirectAccess in different Internet connection scenarios.

The DirectAccess test lab consists of the following collection of computers or virtual machines:

One computer running Windows Server 2008 R2 Enterprise Edition (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 (UAG1) that is configured as the UAG DirectAccess server.

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

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

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

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

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

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

1

The Internet (131.107.0.0/24).

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

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

This guide uses a working UAG DirectAccess test lab as described in Test Lab Guide: Demonstrate UAG DirectAccess. The instructions in this guide assume that you have completed the Demonstrate UAG DirectAccess Test Lab Guide and have a working UAG DirectAccess setup with a single UAG DirectAccess server.

DirectAccess Troubleshooting ToolsWindows 7 and Windows Server 2008 R2 provide many tools for gathering information for DirectAccess problem determination and resolution. The following table lists some commonly used tools and describes their use and purpose for DirectAccess.

Tool Description2

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 by Group Policy.

Use this command to ensure that the DirectAccess client has received the NRPT rules from Group Policy.

netsh namespace show effectivepolicy Displays the active rules in the NRPT.3

http://technet.microsoft.com/en-us/library/ee624046(WS.10).aspx


command

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. DirectAccess client tunnels are not available when the Domain profile is active.

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.

4

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 command

Simulates the DNS queries of DirectAccess clients.

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 DNS server addresses configured on the

5

DirectAccess client’s network interface card (NIC). When using UAG as the DirectAccess server, you would specify the IPv6 address of the UAG DirectAccess DNS server, as listed in the output of the netsh namespace show effectivepolicy command.

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 6




properties.

Use this snap-in to verify that the correct certificates are installed with the correct field values. For more information, see Certificates.

The UAG management console and UAG DirectAccess Wizard

The UAG management console includes the interface for configuring the UAG DirectAccess clients and servers.

UAG DirectAccess Troubleshooting Tools in the Test LabThis section describes the display of key troubleshooting tools when CLIENT1 is connected to the Intranet, Internet, and Homenet subnets. The goal is to provide you with a baseline assessment of what appears in a working environment.

Corpnet SubnetWhen CLIENT1 is attached to the Corpnet subnet, it obtains an IPv4 address configuration, including its DNS server address, from DC1. As an ISATAP host, CLIENT1 also automatically configures an ISATAP address on an ISATAP adapter. Because it is attached to the corpnet, 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.

Before carrying out the following exercises open an elevated command prompt and enter:

Netsh interface teredo set state default

and press ENTER. This helps ensure that the Teredo interface available, as it might have been turned off during a previous exercise.

netsh dnsclient show stateThe 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

7


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). The NRPT rules are not applied when the DirectAccess client is inside the corporate network.

netsh namespace show policyThe 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.contoso.com

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

Certification authority : DC=com, DC=contoso, DC=corp, CN=corp-DC1-CA

DNSSEC (Validation) : disabled

DNSSEC (IPsec) : disabled

DirectAccess (DNS Servers) :

DirectAccess (IPsec) : disabled

DirectAccess (Proxy Settings) : Bypass proxy

Settings for .corp.contoso.com

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



DNSSEC (IPsec) : disabled

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

DirectAccess (IPsec) : disabled


8

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

netsh namespace show effectivepolicyThe 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 Corpnet subnet.

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

Domain Profile:

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

corp.contoso.com

Ok.

CLIENT1 has detected the domain controller for the corp.contoso.com domain (DC1) and the presence of the network location server (APP1). The current profile is identified as Domain Profile and the name of the domain detected is corp.contoso.com. DirectAccess IPsec tunnels are never established when the Domain Profile is activated. The reason for this is that the connection security rules required to activate the DirectAccess IPsec tunnels are not available in the Domain Profile.

Windows Firewall with Advanced Security snap-inFigure 1 shows 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:

9

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

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

ISATAP State : default

CLIENT1 should have the ISATAP component set to the default state, which is enabled as part of the local host setting. This setting is not controlled by group policy in the default UAG DirectAccess deployment or in this test lab.

netsh interface isatap show routerThe 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. You can also control this setting via Group Policy. The default UAG DirectAccess configuration does not control this setting via Group Policy and uses the default behavior of locating the ISATAP router name using DNS queries.

10

ipconfig /allThe 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.contoso.com

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

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

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

DNS Suffix Search List. . . . . . : corp.contoso.com

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : corp.contoso.com

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


Tunnel adapter Teredo Tunneling Pseudo-Interface:


11


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


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


Tunnel adapter isatap.corp.contoso.com:

Connection-specific DNS Suffix . : corp.contoso.com

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


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


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 Corpnet subnet), the ISATAP address assigned to the Tunnel adapter isatap.corp.contoso.com interface, and the disconnected state of the Tunnel adapter iphttpsinterface and Tunnel adapter Teredo Tunneling Pseudo-Interface.

Internet subnetWhen CLIENT1 is attached to the Internet subnet, it obtains an IPv4 address configuration, including its DNS server address, from INET1. When a DirectAccess client is connected to a public network and receives a public IP address, it will automatically configure itself as a 6to4 host. 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 Security Associations (SAs).

netsh dnsclient show stateThe 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

12

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. Also note the DirectAccess Settings are Configured and Enabled.

netsh namespace show effectivepolicyThe 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.contoso.com

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



IPsec settings : disabled

DirectAccess (DNS Servers) :


Settings for .corp.contoso.com

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



IPsec settings : disabled

DirectAccess (DNS Servers) : 2002:836b:3::836b:3


Because CLIENT1 cannot access network location URL https://nls.corp.contoso.com, it does not remove the two DirectAccess rules from the active NRPT. Notice that the DirectAccess (DNS

13

Servers) setting is the 6to4 address assigned to the UAG DirectAccess server. The reason for this is that UAG DirectAccess clients use the DNS64 proxy to resolve names on the intranet.

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

Public Profile:

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

Identifying…

Ok.

CLIENT1 has not detected the domain controller for the corp.contoso.com domain (DC1) and the presence of the network location server (APP1) on the Internet subnet. This prevents the Domain Profile to be active and the Public Profile is then used by Windows Firewall with Advanced Security.

Windows Firewall with Advanced Security snap-inThe 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:

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:

14

Note that you may not see all the Main Mode entries that you see in this figure. If you want to see entries similar to these, open a command prompt on CLIENT1 and enter net view \\app1 and press ENTER. This will generate the Kerberos entries for the Main Mode connections, since APP1 is not a member of the management servers collection that is accessible through the infrastructure tunnel, and therefore requires access through the intranet tunnel, which uses user account based Kerberos authentication.

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:

If you do not see these entries, you can run the new view \\app1 command and then check the Quick Mode entries again. If you do not see them, refresh the display by using the F5 key on the keyboard.

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.

15

Note: Quick mode IPsec SAs can time-out and be automatically removed. To reinitialize them, run the net view \\app1 command in a command prompt window on CLIENT1 and refresh the list of quick mode SAs with the F5 key while in the Windows Firewall with Advanced Security console.

netsh interface 6to4 show stateThe 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 : default

Undo on Service Stop : default

netsh interface 6to4 show relayThe 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 (UAG1).

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


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


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




Ethernet adapter Local Area Connection 2:




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


16


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

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

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

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


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







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







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


Tunnel adapter 6TO4 Adapter:

Connection-specific DNS Suffix . : isp.example.com

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


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


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

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

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


Tunnel adapter isatap.isp.example.com:


Connection-specific DNS Suffix . : isp.example.com

17



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


Notice the public (non-RFC 1918) 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, and the disconnected state of the Tunnel adapter iphttpsinterface interface and Teredo interface.

Homenet subnet with Teredo connectivityWhen CLIENT1 is attached to the Homenet subnet, it obtains an IPv4 address configuration, including its DNS server address, 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 currentprofileThe following is the display of the netsh advfirewall monitor show currentprofile command on CLIENT1 when it is connected to the Homenet subnet:

Private Profile:

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

Network

Ok.

CLIENT1 has been assigned a private IPv4 address and has not detected the domain controller for the corp.contoso.com domain (DC1) and the presence of the network location server (APP1) on the Homenet subnet. For these reasons the Domain Profile is not enabled.

netsh interface teredo show stateThe 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 : client

Server Name : 131.107.0.2 (Group Policy)

Client Refresh Interval : 30 seconds

Client Port : unspecified

State : qualified

Client Type : teredo client

Network : unmanaged

NAT : restricted

18

NAT Special Behaviour : UPNP: No, PortPreserving: No

Local Mapping : 192.168.137.65:60151

External NAT Mapping : 131.107.0.100:60151

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


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


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








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



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

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

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

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


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







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



Connection-specific DNS Suffix . :19



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


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

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

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


Tunnel adapter isatap.mshome.net:


Connection-specific DNS Suffix . : mshome.net



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


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

Homenet subnet with IP-HTTPS connectivityWhen 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 interfacesThe 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 : https://uag1.contoso.com:443/IPHTTPS

Last Error Code : 0x0

Interface Status : IPHTTPS interface active

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


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

20


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








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



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

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

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

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


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






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


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


Tunnel adapter isatap.mshome.net:


Connection-specific DNS Suffix . : mshome.net



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


21

Notice the global address assigned to the Tunnel adapter iphttpsinterface. Note that your exact IPv6 address for the iphttpsinterface might vary, but will begin with 2002: Keep in mind that the Teredo interface is currently disabled. You will need to enable the Teredo interface again in order to establish a Teredo connection to the DirectAccess server. At this point, leave the Teredo interface disabled as we will use the current configuration later in this document.

Troubleshooting DirectAccess Client Connectivity ProblemsThe 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 and the troubleshooting tools described in this white paper 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 (UAG1) to access the UAG DirectAccess DNS proxy on UAG1 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.

Procedure to break the configurationFollow these steps to configure the DirectAccess test lab for this troubleshooting scenario.

To configure DirectAccess to use the wrong root CA for IPsec authentication

1. Shut down CLIENT1 and move CLIENT1 to the Corpnet subnet. Start CLIENT1 and log in as CORP\User1. Verify that CLIENT1 can reach DC1 using ping.

2. On UAG1, click Start, click Microsoft Forefront UAG, and click Forefront UAG Management.

3. In the Microsoft Forefront Unified Access Gateway Management console, click DirectAccess in the left pane of the console. Click Edit in the DirectAccess Server section. On the Connectivity page, click Next. Then click Next on the Managing DirectAccess Services page.

4. On the Authentication Options page, under the Use root certificate option, click Browse.

5. In the list of certificates, click Microsoft Root Authority, click OK. Note on the bottom of

22

the Authentication Options page that there is a warning that there is no computer certificate issued by this CA. Click Finish.

6. Click the Generate Policies button. On the Forefront UAG DirectAccess Configuration Review page, click Apply Now. Click OK in the DirectAccess Policy Configuration dialog box.

7. Click Close on the Forefront UAG DirectAccess Configuration Review page.

8. Open an elevated command prompt and enter gpupdate /force. Wait for the command to complete and then close the command prompt window.

9. In the Microsoft Forefront Unified Access Gateway Management console, click File and then click Activate. In the Activate Configuration dialog box, click Activate. Click Finish in the Activate Configuration dialog box.

10. Close the Microsoft Forefront Unified Access Gateway Management console.

11. On CLIENT1, run an elevated Command Prompt.

12. In the Command Prompt window, run the gpupdate /force command.

13. Disconnect CLIENT1 from the Corpnet subnet, wait 30 seconds, and then connect it to the Internet subnet.

14. 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 troubleshootingFrom the previous procedure, it appears that UAG1, the intranet DNS proxy, is not resolving intranet names. Use the following procedures to determine the root cause of the problem.

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. This is consistent with the fact that the DirectAccess could not establish an HTTPS connection to the Network Location Server on the Corpnet subnet.

2. From the Command Prompt window, ping the IPv6 address listed in the .corp.contoso.com NRPT rule, which is 2002:836b:3::836b:3. You should get a successful response from this address. This indicates that you can communicate with the UAG DirectAccess server through a non-IPsec connection. The reason for this is that by

23

default, ICMP is exempt from IPsec protection.

3. In the Command Prompt window, ping 2002:836b:2:8000:0:5efe:10.0.0.1. You should get a successful response from this address. This is the ISATAP address of DC1 on the Corpnet subnet. This step demonstrates that routing from the DirectAccess client to a host on the Corpnet subnet is successful.

4. From the Command Prompt window, use the nslookup -q=aaaa dc1.corp.contoso.com 2002:836b:3::836b:3 command to resolve the fully qualified domain name (FQDN) for DC1 (dc1.corp.contoso.com). You should not receive a response from DC1, which indicates a possible issue with connecting using protocols other than ICMP (nslookup uses DNS protocol based queries) which require that IPsec tunnels be established first. The next step is to verify that CLIENT1 has established IPsec SAs with UAG1.

5. Click Start, type wf.msc, and then press ENTER.

6. In the console tree, open Monitoring/Security Associations/Main Mode and Monitoring/Security Associations/Quick Mode. There should be no IPsec SAs.

7. From the Command Prompt window, run the netsh advfirewall monitor show currentprofile command. This should display the client is using the Public Profile. This is the correct Profile that should be assigned to client off the corpnet network.

8. On DC1, open the Group Policy Management console from the Administrative Tools menu.

9. In the Group Policy Management console, navigate to Forest:corp.contoso.com\Domains\corp.contoso.com\UAG DirectAccess: DaServer {GUID}. Right click on that Group Policy Object and click Edit.

10. In the Group Policy Management Editor, navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Windows Firewall with Advanced Security – LDAP://…\Connection Security Rules.

11. Double click on the UAG DirectAccess Gateway – Clients Access Enabling Tunnel – All.

12. In the UAG DirectAccess Gateway – Clients Access Enabling Tunnel – All dialog box, click the Authentication tab.

13. On the Authentication tab, click the Customize button.

14. In the Customize Advanced Authentication Methods dialog box, in the First authentication section, in the list of First authentication methods, expand the

24

Additional Information column and scroll to the right. Note the CN=Microsoft Root Certificate Authority entry.

15. Click Cancel in the Customize Advanced Authentication Methods dialog box. Click Cancel in the UAG DirectAccess Gateway – Clients Access Enabling Tunnel – All dialog box. Close the Group Policy Management Editor. Close the Group Policy Management console.

16. Return to CLIENT1. Open an elevated command prompt. At the command prompt, enter certutil –store my and press ENTER. Notice the issuer is CN=corp-DC1-CA.

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 computer certificates issued to UAG1 and CLIENT1 chain to the Microsoft Root Authority, certificate authentication cannot complete and the IPsec tunnels needed to access the Corpnet subnet cannot be established. This troubleshooting exercise is especially instructive because it demonstrated the fact that ICMP communications do not require IPsec protection by default, with the result being that pings to the IPv6 address of the UAG1 DirectAccess server were successful, but the nslookup connection failed, since the DNS protocol requires that the IPsec tunnels be established.

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

To configure UAG DirectAccess to use the correct root CA for IPsec authentication

1. On UAG1, click Start, click Microsoft Forefront UAG, and click Forefront UAG Management.

2. In the Microsoft Forefront Unified Access Gateway Management console, click DirectAccess in the left pane of the console. Click Edit in the DirectAccess Server section. On the Connectivity page, click Next. Then click Next on the Managing DirectAccess Services page.

3. On the Authentication Options page, under the Use root certificate option, click Browse.

4. In the list of certificates, click corp-DC1-CA, click OK, and then click Finish.

5. Click the Generate Policies button. On the Forefront UAG DirectAccess Configuration Review page, click Apply Now. Click OK in the DirectAccess Policy Configuration dialog

25

box.

6. Click Close on the Forefront UAG DirectAccess Configuration Review page.

7. Open an elevated command prompt and enter gpupdate /force. Close the command prompt window.

8. In the Microsoft Forefront Unified Access Gateway Management console, click File and then click Activate. In the Activate Configuration dialog box, click Activate. Click Finish in the Activate Configuration dialog box. Close the Microsoft Unified Access Gateway Management console.

9. Shut down CLIENT1 and then return it to the Corpnet subnet. Start CLIENT1 and log on a CORP\User1. On CLIENT1, run an elevated Command Prompt.

10. In the Command Prompt window, run the gpupdate /force command. Wait for the command to complete and close the command prompt window.

11. Disconnect CLIENT1 from the Corpnet subnet, wait 30 seconds, and then connect it to the Internet subnet.

12. From the Command Prompt window, run the ping app1 command. This command should complete successfully.

Cannot resolve intranet FQDNs (root cause 2)Unlike the Windows DirectAccess solution where the DirectAccess client communicates with the DNS server on the intranet through the infrastructure tunnel, UAG DirectAccess clients do not communicate directly with the intranet DNS server to resolve intranet host names. Instead, the UAG DirectAccess clients send DNS queries to the DNS64 service on the UAG DirectAccess server. DNS64 acts as a DNS proxy that forwards the DNS requests from the DirectAccess clients to the DNS servers configured on the internal interface of the UAG DirectAccess server.

In this troubleshooting scenario, you will disable the DNS64 service on the UAG DirectAccess server and observe the effects it has on the UAG DirectAccess clients.


To configure UAG1 to disable the NAT64 service

1. Connect CLIENT1 to the Homenet subnet. Verify that CLIENT1 can run the net view \\DC1 command from a command prompt window by receiving a list of share names.

26

2. On UAG1, click Start and then enter services.msc into the Search box and press ENTER.

3. In the Services console, locate Microsoft Forefront UAG DNS64 Service and press ENTER.

4. Right click Microsoft Forefront UAG DNS64 Service and click Stop. Close the Services console.

5. Return to CLIENT1. Open a command prompt and enter ipconfig /flushdns and press ENTER. Ping APP1. The ping request will fail and indicate that it could not find app1.

Step-by-step troubleshootingFrom the previous procedure, it appears that name resolution is failing. Use the following to determine the root cause of the problem.


1. On CLIENT1, from the Command Prompt window, run the netsh namespace show effective command. You should see the two NRPT rules. This is consistent with the fact that CLIENT1 was unable to create an HTTPS connection with the Network Location Server. The Name Resolution Policy Table is disabled when the DirectAccess client can connect to the Network Location Server.

2. From the Command Prompt window, ping the IPv6 address listed in the .corp.contoso.com NRPT rule, which is 2002:836b:3::836b:3. You should be able to ping this address successfully. This is the 6to4 address of the UAG DirectAccess server.

3. In the Command Prompt window, ping 2002:836b:2:8001::a00:1. This is the NAT64 address for DC1 and indicates that NAT64 is working correctly (learn more about NAT64 addresses on the Edge Man Blog. You should get a successful response from this address. This step demonstrates that routing from the DirectAccess client to a host on the Corpnet subnet is successful.

3. From the Command Prompt window, use the nslookup -q=aaaa dc1.corp.contoso.com 2002:836b:3::836b:3 command to resolve the FQDN for APP1. You should not receive a response from UAG1. While this might indicate a name resolution issue, it might also represent a problem with IPsec tunnel establishment which would block the DNS protocol, as you learned in the previous exercise.

3. At UAG1, click Start and then click Forefront TMG. Click Forefront TMG Management.

3. In the Forefront TMG management console, click the Logs & Reports node in the left

27

http://blogs.technet.com/b/tomshinder/archive/2010/07/14/considerations-when-using-ping-to-troubleshoot-directaccess-connectivity-issues.aspx

pane. In the right pane, click the Tasks Tab and click Start Query.

3. At CLIENT1, open a command prompt and type ping app1 and press ENTER. The name resolution attempt will fail.

3. At UAG1, click Stop Query in the Tasks Tab. Review the log entries. You should see no DNS queries being sent to the DNS server at 10.0.0.1. Leave the TMG console open.

4. At CLIENT1, 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, let’s assess non-ICMP connection between CLIENT1 and DC1.

6. From the Command Prompt window, use the net view \\2002:836b:2:8000:0:5efe:10.0.0.1 command to attempt to connect to DC1. This command should be successful, indicating that DC1 is processing file sharing traffic and confirms non-ICMP protocol traffic is enabled to the intranet. Note that you cannot connect to this address from the Run command. Net View works because it’s performed in the context of the machine account.

7. Move to UAG1. At UAG1, open a command prompt and ping DC1 and APP1. You should receive ping responses from both machines, indicating that name resolution is working internally.

8. Open the services.msc console. In the right pane of the console, click the Startup Type column so that Automatic start up services are located near the top of the list. Check to see if any services configured for Automatic startup are not listed as Started. You should see that Microsoft Forefront UAG DNS64 Service is not started.

9. Right click on Microsoft Forefront UAG DNS64 Service and click Start.

9. At UAG1, click Start Query in the TMG console.

9. At CLIENT1, open a command prompt and ping APP1. You should get four successful responses.

9. At UAG1, click Stop Query in the TMG console. Review the log file entries and note the DNS queries sent from UAG1 (10.0.0.2) to DC1 (10.0.0.1), indicating that the DNS64 service is now forwarding queries to DC1.

28

This is the root cause of the problem. The UAG DNS64 service was disabled, which caused name resolution to fail for the DirectAccess clients. This represents an important distinction from how the Windows DirectAccess solution works. Windows DirectAccess clients contact the DNS servers on the intranet for name resolution. UAG DirectAccess clients contact the DNS64 proxy on the UAG DirectAccess server for name resolution. Note that you can disable the DNS64 service in the UAG DirectAccess Wizard. In that scenario, you would configure internal DNS servers to be available through the infrastructure tunnel. However, if you choose this configuration, integrated support for NAT64/DNS64 will not be available.

Correct the configuration procedureYou do not need to perform any steps to restore the configuration as you enabled the DNS64 service as part of the troubleshooting exercise.

Cannot access the CorpnetDirectAccess tunnels require two forms of authentication: computer certificate authentication and account authentication. Account authentication is performed using NTLMv2 for the computer account to establish the infrastructure tunnel. Account authentication is performed using Kerberos for the logged on user account to establish the intranet tunnel.

In this troubleshooting scenario, you will disable the computer account for CLIENT1 and use troubleshooting techniques to evaluate client and server behavior in this scenario.


To disable the CLIENT1 computer account:

1. At DC1, open the Active Directory Users and Computers console.

2. In the Active Directory Users and Computers console, expand the corp.contoso.com node in the left pane of the console and click the Computers node.

3. In the right pane of the console, right click CLIENT1 and click disable. Click Yes in the dialog box indicating that disabling the account will present users from logging into the domain. Click OK in the dialog box indicating that the account was disabled.

4. Shut down CLIENT1.

Step-by-step troubleshootingThe following troubleshooting steps investigate name resolution, connectivity and IPsec security association information to help determine the cause of the problem.

29

To troubleshoot this scenario:

1. At UAG1, open an elevated command prompt and enter the following: auditpol /set /subcategory:”IPsec Main Mode”,“IPsec Extended Mode” /success:enable /failure:enable and press ENTER. You should see a The command was successfully executed response. This enables logging for IPsec Main Mode and Extended Mode connections, which are used to establish the DirectAccess tunnels.

2. In the elevated command prompt windows, enter netsh advfirewall monitor delete mmsa all to delete all existing Main Mode IPsec security associations.

3. Restart CLIENT1 and log on as CORP\User1.

4. Open an elevated command prompt. In the command prompt window, enter ipconfig /all and press ENTER. You should see that the Tunnel adapter iphttpsinterface shows a Media State of Media disconnected.

5. There appears to be a problem establishing an IP-HTTPS connection. To confirm that the problem is with IP-HTTPS, you can enable Teredo. Recall that we had disabled Teredo earlier in this document so that you could test IP-HTTPS from behind the NAT device.

6. To enable Teredo, in the command prompt window, enter netsh interface Teredo set state enterpriseclient. You should see an Ok response.

7. In the command prompt window, enter ipconfig /all and press ENTER.

8. You should now see Tunnel adapter Teredo Tunneling Pseudo-Interface enabled with an IP address that begins with 2001:

9. In the command prompt window, ping DC1. The ping attempt should fail, with an indication that there was a name resolution failure. Ping APP1. You should see the same result.

10. In the command prompt window, enter netsh namespace show effectivepolicy and press ENTER. You show see entries for nls.corp.contoso.com and .corp.contoso.com in the NRPT, indicating that the NRPT is active.

11. To test whether Teredo is working correctly and connecting to the UAG DirectAccess server, ping the IP address of the UAG server, which is listed in the NRPT printout. In the command prompt window, enter ping 2002:836b:3::836b:3 and press ENTER. The ping succeeds, indicating that Teredo is working correctly and allowing traffic to the UAG DirectAccess server.

30

12. To test connectivity to the Corpnet subnet, ping DC1 using it’s IPv6 address on the Corpnet subnet. In the command prompt window, enter ping 2002:836b:2:8000:0:5efe:10.0.0.3 and press ENTER. The ping should be successful. This indicates that UAG1 is able to relay the Teredo traffic to an IPv6 resource on the intranet. However, keep in mind that ICMP traffic is exempted from IPsec policy.

13. Open Internet Explorer and attempt to open the default web site on APP1 using the server’s IPv6 address. In the Internet Explorer address bar, enter http://[2002:836b:2:8000:0:5efe:10.0.0.3] and press ENTER. Internet Explorer should not be able to connect to the web site. This indicates that while Teredo traffic is relayed to the Corpnet, there is a connectivity problem to APP1 that appears to be related to the IPsec tunnels. Note that this connection attempt with Internet Explorer is done in the context of the logged on user account and that APP1 is not on the list of management servers.

14. Return to the command prompt window. Enter net view \\2002:836b:2:8000:0:5efe:10.0.0.3 and press ENTER. You should see a System error 53 has occurred indicating that CLIENT1 was not able to connect to APP1 to enumerate the shares. Enter net view \\2002:836b:2:8000:0:5efe:10.0.0.1 and press ENTER. You should see a list of the shares on DC1. Note that these connection attempts are made in the context of the logged on user and that APP1 is not on the list of management servers and that DC1 is on the list of management servers.

15. At the command prompt enter ping dc1.corp.contoso.com and press ENTER. You should see a report that Ping request could not find host dc1.corp.contoso.com indicating a DNS name resolution failure. Note that the DNS64 proxy is on UAG1 and that UAG1 is not on the list of management servers and that the DNS query is done in the context of the local computer account.

16. At UAG1, click Start and enter wf.msc in the Search box and press ENTER. In the Windows Firewall with Advanced Security console, navigate to Monitoring\Security Associations\Main Mode. You should find that there are one or more Main Mode Security Associations that have NTLMv2 listed as the 2nd Authentication Method. .

17. In the Windows Firewall with Advanced Security console, navigate to Monitoring\Security Associations\Quick Mode. You may see one of more Quick Mode Security Associations. If you do not see any Quick Mode Security Associations it indicates that they have timed out.

18. Click Start and enter eventvwr.msc in the Search box and press ENTER.

19. In the Event Viewer console, navigate to Windows Logs\Security. In the Task Category 31

column, scroll through the records and locate an entry for IPsec Extended Mode and double click on that entry. In the General tab you will see information indicating that the IPsec extended mode negotiation failed. Scroll through the information and locate the Remote Endpoint information. Note that the IPv6 Teredo address of CLIENT1 is listed as the remote endpoint. Scroll farther down and locate the Failure Information. The failure information indicates that the Failure Reason as IKE authentication credentials are unacceptable. Close the Event Properties dialog box.

20. Right click the Security node in the left pane of the console and click Filter Current Log. In the Filter Current Log dialog box, in the Filter tab, enter in the Event ID text box the value 4625 and click OK. Double click the most recent entry. Note the Account for which logon failed is CLIENT1$. Scroll through the information and locate the Failure Information section. Note the Failure Reason is Account currently disabled. Click Close in the Event Properties dialog box.

21. Close the Event Viewer and Windows Firewall with Advanced Security consoles. Close all command prompt windows.

The root cause of the problem is that the computer account for the DirectAccess client is disabled. There are several issues of note in this troubleshooting exercise. Recall that you were able to ping APP1 but you were not able to use the net view command to see the shares on APP1. Also, recall that you were not able to reach the web site on APP1. You were able to ping DC1 and you were able to enumerate the shares on DC1. However, you were not able to resolve the name of DC1.

The reason why you could not connect to APP1 using a non-ICMP protocol is that APP1 was not a member of management servers list. Remember that management servers are available through the infrastructure tunnel. This becomes important when you think about the Security Associations viewed in the Windows Firewall with Advanced Security console – the only Security Associations were those that used NLTMv2 authentication, which is consistent with the infrastructure tunnel. The intranet tunnel could not be opened because computer account authentication failed and therefore no Kerberos authentication was available. This means the only connectivity available was through the infrastructure tunnel using the credentials of the logged on user. Any resource not available through the infrastructure tunnel would not be reachable using any non-ICMP protocol.

Also of interest is why the IP-HTTPS adapter failed to initialize while the Teredo adapter was successful. The reason for this is that when the DirectAccess client establishes an IP-HTTPS connection with the UAG DirectAccess server, mutual computer certificate authentication takes place. The DirectAccess client computer’s certificate is mapped in Active Directory to the name

32

of the computer. Since the DirectAccess client did not have a valid computer account, the client was not able to successfully authenticate and the IP-HTTPS tunnel establishment failed.


To enable the CLIENT1 computer account:

1. At DC1, open the Active Directory Users and Computers console.

2. In the Active Directory Users and Computers console, expand the corp.contoso.com node in the left pane of the console and click the Computers node.

3. In the right pane of the console, right click CLIENT1 and click Enable Account. Click OK in the dialog box indicating that the account was enabled.

4. Shut down CLIENT1.

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.


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 left pane of the console, 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.contoso.com, and then click OK.

33

Click Close in the Site Bindings dialog box.

6. Connect CLIENT1 to the intranet subnet and then start CLIENT1. Log in as CORP\User1.

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 to the ISATAP tunnel adapter. CLIENT1 cannot resolve the name ISATAP to reach the intranet ISATAP server and configure the Tunnel adapter isatap.corp.contoso.com interface.

Step-by-step troubleshootingFrom 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 procedures are used to determine the root cause of the problem.


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, which is https://nls.corp.contoso.com.

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.contoso.com).

4. From the Command Prompt window, ping the FQDN in the network location URL. This command should be successful. The reason for this is that the Network Location Server name is exempted for the NRPT. Because of this exemption, the DNS query request is sent to the DNS server configured on CLIENT1’s NIC, and not to the NAT64 DNS proxy on the UAG DirectAccess server. CLIENT1 cannot reach the UAG1 DNS proxy because it does not have an IPv6 enabled interface to reach the DNS address reported in the NRPT.

5. Open Internet Explorer, enter the network location URL (https://nls.corp.contoso.com)

34

https://nls.corp.contoso.com/

https://nls.corp.contoso.com/

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. The subject name on the certificate must match the name used to connect to the web site. Unlike what you can do through Internet Explorer to “click through” this problem, the DirectAccess client doesn’t have such a capability.

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

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



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.contoso.com) does not match the FQDN from the network location URL (nls.corp.contoso.com).

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 HTTPS-based network location URL, network location detection fails and CLIENT1 determines that it is connected to the Internet, rather than the intranet.


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 left pane of the console, open APP1\Sites, and then click Default Web Site.



35

5. In Edit Site Binding, in SSL certificate, click nls.corp.contoso.com, and then click OK. Click Close in the Site Bindings dialog box.

6. Restart CLIENT1.

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.contoso.com that begins with 2002:836b:2.

Additional ResourcesFor procedures to configure the Base Configuration test lab on which this document is based, see the Test Lab Guide: Base Configuration.

For the design and configuration of your pilot or production deployment of DirectAccess, see the Forefront UAG DirectAccess design guide and the Forefront UAG DirectAccess deployment guide.

For information about troubleshooting DirectAccess, see the DirectAccess Troubleshooting Guide.

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

36

Introductiondownload.microsoft.com/.../TestLabGuide_Troublesho… · Web viewTest Lab Guide:...

Documents

Transcript of Introductiondownload.microsoft.com/.../TestLabGuide_Troublesho… · Web viewTest Lab Guide:...