UAG DA Manage-out another mystery-intranet firewall.

  • Article

We know there are certain basic requirements or shall i say pre-requisites for the UAG DA manage out scenario to work. I was engaged on a case recently ,where the consultant started  with listing out, what he has in place to make sure UAG DA manage out should be working. He was right in the items he mentioned.

For benefit of readers , I m putting certain parts of the list.

  • DirectAccess client has registered its IPv6 address and name in DNS and that it can be resolved by the Inside-Out management machine. 
  • The Inside-Out management machine is configured with IPv6 via ISATAP
  • The Inside-Out management machine has registered its IPv6 address and name in DNS and can be resolved successfully. 
  • The ISATAP router name is resolving to the internal interfaces of the DirectAccess server acting as the ISATAP router, the 2 x servers dedicated IP addresses plus the virtual IP address, so 3 addresses in total all resolving to the ISATAP name.  
  • The Intranet Firewall is allowing Protocol 41 (IPv6 encapsulation) to UAG servers in both directions.  
  • Any required, client side firewall rules are in place on the remote DirectAccess clients.
  • The Inside-Out management machines have been added to the management servers group on the DirectAccess servers, so as to allow management before the remote user logs on and establishes the Intranet tunnel.  
  • Not affected by the setting in this article DirectAccess Manage Out fails for any non-ICMP traffic in Forefront Unified Access Gateway 2010, causing custom security policies regarding the local security rights for the DirectAccess Manage-Out machine and clients (modifying the setting "Access this computer from the network").

Above list is very comprehensive, prepared by the consultant and if we have all this in place then UAG DA inside-out access should work. In this particular scenario UAG DA outside in access i.e. the usual remote access was working. In customer environment, they were using IP-HTTPS hence edge traversal was also out of question as per Tom Shinder's  post here https://blogs.technet.com/b/tomshinder/archive/2010/12/01/uag-directaccess-and-the-windows-firewall-with-advanced-security-things-you-should-know.aspx

 

 

Troubleshooting/Data analysis/Solution

 

To Start with I started looking at the first end point of this scenario i.e. the server from which we were trying to access the external DA client machine. Found that the server was not getting the ISATAP IPV6  address(seen in the output of the Ipconfig /all on the server). So my chain of thoughts started with this theory i.e. We know that ISATAP client will get its IP address from the ISATAP router and to reach ISATAP router,first it should be able to resolve name ISATAP.  So I checked, if server is able to resolve the ISATAP to the UAG DA server's VIP and we pinged ISATAP from the command prompt  of the server, that did resolve to the UAG DA server's VIP.

We took DA scenario tracing from the server and the UAG DA server nodes, while restarting IP helper service on the server(from where we were trying to connect the DA client). In the traces i found that UAG DA server was getting the Router solicitations but it was not sending back the Router advertisement back which does the Ip provisioning and ISATAP  client gets the IPV6 address. you can double click on the image below to zoom it.

 

Since UAG DA server has TMG on it as well, I looked at the TMG live logs while restarting the IP helper service on the Server (from where we were trying to connect the DA client). From TMG live logs , we could see that TMG was allowing the traffic ,no denying of this traffic from the server. We also removed a third party anti virus from the UAG DA server to rule out if that could be dropping the packets. We finally found out that the intranet firewall between the UAG DA server and the internal server(from where we were trying to connect the DA client) was blocking the IP protocol 41, Once it was allowed , server (from where we were trying to connect the DA client) started getting IPV6 ISATAP address and inside-out started working fine. 

So in the end , I would say the list above is really good and we can use it as check list and would like to appreciate the consultant who put that list, we just need to make sure we are implementing each point correctly.