Troubleshooting DirectAccess Manage Out Connections

imageThis week we move a little outside of our traditional cloud content, but not too much. This article is about imagetroubleshooting DirectAccess Manage Out connections. There are discussions about how to use DirectAccess in a cloud solution, so this is not entirely out of our scope. This is especially true when you consider that one of the essential characteristics of cloud computing is ubiquitous connectivity, and that’s what DirectAccess is all about!

A big thanks to THANK YOU to Colin Brown for this contribution.


imageThe following are some troubleshooting steps if you run into problems getting inside-out management working.  Inside-out management is the ability for a machine on the internal corporate network, such as a helpdesk machine, to be able to initiate communications to remote, internet-based DirectAccess clients, such as by using RDP sessions, remote registry, or mapping drives.

1. Ensure the remote DirectAccess client has registered its IPv6 address and name in DNS and that it can be resolved by the Inside-Out management machine.  The IPv6 address will correlate to which ever connection mechanism the client is using, either:

a. Native IPv6 (unlikely)

b. 6to4

c. Teredo

d. IP-HTTPS

Note.  A link local IPv6 address will not work.

2. Ensure the Inside-Out management machine is configured with IPv6 via ISATAP (this could also be native IPv6 but we will assume ISATAP).

Note.  A link local IPv6 address will not work.

If the Inside-Out management machine is not receiving an ISATAP address, check

a. All the ISATAP IP addresses are registered (see point 4 below)

b. That all the ISATAP IP addresses are all in the same subnet, and that the subnet mask allocated is correct

c. That the Intranet firewall is allowing Protocol 41 (See point 5 below)

3. Ensure the Inside-Out management machine has registered its IPv6 address and name in DNS and can be resolved successfully. This will be the machines ISATAP IPv6 address.

If the helpdesk machine does not have an ISATAP address refresh ISATAP (and other) settings from the command line using one of the following commands:

i. SC CONTROL IPHLPSVC PARAMCHANGE

Or

ii. NET STOP IPHLPSVC then NET START IPHLPSVC

4. Ensure the ISATAP router name is resolving to the internal interfaces of the DirectAccess server acting as the ISATAP router from the internal network, or other ISATAP router if you are using one.

a. In a WNLB 2-node array, this would be the 2 x servers dedicated IP addresses plus the virtual IP address, so 3 addresses in total all resolving to the ISATAP name. 

5. Ensure that the Intranet Firewall is allowing Protocol 41 (IPv6 encapsulation) to UAG servers in both directions. Do not confuse Protocol 41 with Port 41. IPv6 Encapsulation is a protocol like TCP or UDP, not a Port.

6. Ensure any required client side firewall rules are in place on the remote DirectAccess clients with Edgetraversalallowed

a. ICMPv4 for pinging IPv4 addresses

b. ICMPv6 for pinging IPv6 addresses

c. F&P for whichever services you require, such as SMB file share mapping

d. Remote Desktop

e. Etc.  Etc.

7. Ensure all the DirectAccess Servers have a valid ISATAP configuration.

a. NETSH INT IPV6

a.1. Find the index number for ISATAP

b. NETSH INT IPV6 SH INT Index#

b.1. Ensure that Forwarding, Advertising and Advertise Default Route, are all enabled

b.2. If not

b.2.1. NETSH INT IPV6 SET INT Index# FORWARDING =EN ADVERTISE=EN ADVERTISEDEFAULTROUTE=EN

b.3. Validate changes

b.3.1. NETSH INT IPV6 SHOW INT Index#

b.4. NET STOP IPHLPSVC

b.5. NET STOP IPHLPSVC

8. Collect some trace logs:

a. NETSH TRACE START SCENARIO=DIRECTACCESS CAPTURE=YES REPORT=YES

b. NET STOP IPHLPSVC

c. NET START IPHLPSVC

d. Wait 10 seconds

e. NETSH TRACE STOP

The logs are called NETTRACE.ETL and NETTRACE.CAB files and will be located in the %TEMP%\NetTraces folder.   Either analyse the logs yourself or send them to your support representative. 

9. Note.  If you want to be able to manage the remote DirectAccess computers even when no one is logged on to them, add the Inside-Out management machines to the management servers group on the DirectAccess servers, where you define Domain Controllers, SCCM and AV machines. Machines defined in these groups can access the client when only the infrastructure tunnel is up, i.e. before the remote user logs on and establishes the Intranet tunnel.  If you have been trying to connect to a remote machine that is not logged on, this could be your problem.

Finally, if the troubleshooting steps have still not helped, just be aware of the issue in this knowledge base article, DirectAccess Manage Out fails for any non-ICMP traffic in Forefront Unified Access Gateway 2010, caused by custom security policies regarding the local security rights for the DirectAccess Manage-Out machine and clients (e.g. modifying the setting "Access this computer from the network").

If you are still having problems you will need to set up network traces from the inside-out management machine, the DirectAccess servers, and the remote DirectAccess client to see where things are going wrong. 

HTH.

Colin Brown, Architect.

Microsoft Consulting Services.


Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, SCD iX Solutions Group
Follow me on Twitter: https://twitter.com/tshinder
Facebook: https://www.facebook.com/tshinder
image

Go Social with Building Clouds! Private Cloud Architecture blog Private Cloud Architecture Facebook page Private Cloud Architecture Twitter account Private Cloud Architecture LinkedIn Group Private Cloud TechNet forums TechNet Private Cloud Solution Hub Private Cloud on the TechNet Wiki