Troubleshooting DirectAccess Manage Out Connections

Troubleshooting DirectAccess Manage Out Connections

  • Comments 4
  • Likes

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 Edge traversal allowed

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: http://twitter.com/tshinder
Facebook:
http://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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • "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"  - This is resolved my Manage Out issue with Windows NLB. But didn't able to understand. I used have only VIP for my ISATAP record. Could you please help by explain little about this. Why we need to have all these 3 IPs for ISATAP DNS Record & how it helps in manage out connection?

  • I asked Jason Jones, from our Microsoft Consulting Services about this - his answer:

    "The reason for needing to add the DIPs as well, is because of the design of the NLB driver on ISATAP.

    When forwarding traffic to the internal server, the underlying IPv4 address in the ISATAP packet is basically the address of the DIP of the UAG server.

    When this packet reaches the internal server, the ISATAP protocol has a security check that verifies whether the packet is sources from another ISATAP host, or in case it was sourced from a different subnet (like in the case of DA clients) then it checks that the IPv4 address is of the ISATAP router itself.

    It does that by checking if the underlying IPv4 address is in the PRL (potential router list), which is basically the A records registered in the DNS for ISATAP. (you can see the PRL by running 'netsh int ipv6 show potentialrouter').

    By adding the DIPs to the DNS, the internal servers are no longer dropping the packets.

    Source: social.technet.microsoft.com/.../d4f5d116-62a4-4652-9e46-1f3a0aacd99b

    Kind regards,

    Jason"

  • Tank you very much for the explanation & community thread. From last 10 days I was trying to figure out why it is not completing TCP three way hand shake.. why my manage out client is not sending Ack after receiving Ack_Syn. Is there any filter driver, tcp half open connection etc... Even premier engineers I was working with from last few days to find out what is going on, they don't have any clue of this. But now it make sense.  Cheers!!

  • Hi Brajesh,

    Thanks! I'll let Jason know that this helped :)

    Tom