none
UAG - Direct Access manage-out not working with IP-HTTPS connected clients RRS feed

  • Question

  • Our Direct Access implementation with UAG 2010 is working great with 6to4, Teredo or IP-HTTPS. Our problem is with manage-out to the DA clients with RDP only when they use IP-HTTPS; Teredo for instance is working fine. We need to use 'Force Tunneling' and thus force the clients into IP-HTTPS.

    To get manage-out working we did the following:

    The result:

    • Management clients activate the ISATAP interface and get the published routes from the ISATAP router (UAG)
    • Pinging the DA clients from management stations always works, so the ISATAP routing on the UAG seems to be OK
    • RDP to the DA clients connected by TEREDO or 6to4 from management stations works, so ISATAP routing on the UAG and the DA client firewall rule seem to be OK

    The problem:

    • as soon as we switch to 'Force Tunneling' or force the DA client into IP-HTTPS, manage-out does not work anymore
    • DA clients cannot connect to any management machine which has ISATAP enabled (pinging is possible however)
    • in the DA clients firewall log are no entries for dropped packets, so it seems the UAG is not forwarding the packets into the IPHTTPS tunnel

    The IPv6 routing on the UAG is configured to forward traffic for IPHTTPS adresses to interface 15, which is the IPHTTPS interface:

    15    306 2002:x:y:8100::/64 On-link

    The persistent route on the UAG is as followes:

    0 4294967295 2002:x:y:8100::/64 On-link (I wonder, why this route is necessary at all)

    So I suspect a routing problem between ISATAP and the IPHTTPS interface on the UAG server, because any communication between the IPHTTPS client and an ISATAP enabled host seems to be completely broken.

    Thomas


    TomSTS

    Saturday, March 31, 2012 3:03 PM

All replies

  • Some further testing shows, that the problem only exist, if IPHTTPS is activated and the intranet target uses ISATAP addressing, which breaks communication completely. Is this problem is solved, manage-out will most certainly work as well.

    A Network Monitor check on an intranet target when starting RDP from an DA client shows traffic hitting the ISATAP interface with the IPv6 address of the DA client and a target port of 3389, which proofs, that the routing and decryption on the UAG is working correctly. The ISATAP host then send a reply to the DA client, which obviously does not get there. 


    TomSTS

    Monday, April 2, 2012 9:48 AM
  • I'm seeing similar behaviour...did you manage to workaround the issue??

    Carl Barrett | Twitter: @Mosquat

    Tuesday, June 26, 2012 8:24 AM
  • We opened a case with Microsoft and they confirmed the configuration to be OK (the usual certificate stuff, routing etc.) but could not help us otherwise. We reinstalled the server and installed a new system in  our test environment, all with the same negative results.

    We could however pinpoint to problem to the UAG's WFP (Windows Filtering Platform), which simply drops all ISATAP based traffic from our internal manage-out clients which is destined for an IPHTTPS external Client (no matter who initiated the connection), expecting it to be encrypted. If WFP auditing is enabled on the UAG we can actually see the problem in the security eventlog (ID 4963):

    IPsec dropped an inbound clear text packet that should have been secured. If the remote computer is configured with a Request Outbound IPsec policy, this might be benign and expected.  This can also be caused by the remote computer changing its IPsec policy without informing this computer. This could also be a spoofing attack attempt.

    This is where Microsoft support went clueless, they are guessing, that the internal ISATAP interface is considered 'unknown' and not a trusted domain network by the firewall.  The question is, why the problems only occur with IPHTTPS clients; Teredo and 6to4 communicate without problems with our ISATAP enabled hosts.

    I suspect, that the IPHTTPS prefix 2002:xxxx:yyyy:8000::/49 might be a problem, as this is also part of Endpoint 1 in the connection security rule (which is not the case for Teredo).


    TomSTS


    • Edited by TomSTS Wednesday, June 27, 2012 5:28 AM
    Wednesday, June 27, 2012 5:20 AM
  • I suspect, that the IPHTTPS prefix 2002:xxxx:yyyy:8000::/49 might be a problem, as this is also part of Endpoint 1 in the connection security rule (which is not the case for Teredo).

    Hi Tom,

    Did you try restarting the  DirectAccess server and see if that solves the problem?

    Additionally, to test your theory with the /49 prefix, when you generate the policy provisioning script, you may export it to a file, and modify the UAGDA_PREFIX_CORP parameter to 2002:xxxx:yyyy:8000::/64 instead of 2002:xxxx:yyyy:8000::/49.

    See here for more info on modifying the script:  http://technet.microsoft.com/en-us/library/ee406218.aspx



    Monday, July 2, 2012 3:33 PM
  • "The question is, why the problems only occur with IPHTTPS clients; Teredo and 6to4 communicate without problems with our ISATAP enabled hosts."

    Ah...that's where we differ - doesnt seem to work for any of our DA clients right now....


    Carl Barrett | Twitter: @Mosquat

    Tuesday, July 3, 2012 4:57 PM
  • Hi Tom,

    We are facing here the same issue too, with our initial problem that DA-clients connected by IP-HTTPS can't be managed from the Intranet. The behaviour has been acknowledged by Microsoft but still under investigation. Keeps you posted when an update is available.

    Regards,

    Ronny


    Ronny de Jong | inovativ.nl | Blog: donnystyle.wordpress.com | Twitter: twitter.com/ronnydejong


    Thursday, July 5, 2012 2:45 PM
  • One change that has helped me is this one here:

    http://support.microsoft.com/kb/2663354

    HOpe it helps someone else too


    Carl Barrett | Twitter: @Mosquat

    Tuesday, July 10, 2012 3:28 PM
  • Hi Carl,

    Just to let you know this update doesn't solved our problem. The problem may be caused by the fact ISATAP is considered unidentified and thus is assigned Public Profile by Firewall. So the public rule UAG DirectAccess Gateway - Clients Corp Tunnel will be applied to ISATAP interface too and would be dropped. Currently some tests will be performed to change the IPv6 suffix of endpoint 1 part of UAG DirectAccess Gateway - Clients Corp Tunnel.


    Ronny de Jong | inovativ.nl | Blog: donnystyle.wordpress.com | Twitter: twitter.com/ronnydejong

    Thursday, August 9, 2012 6:35 AM
  • Question. Do you have a UAG array?

    If so, make sure that at least three DNS records are created for ISATAP functionality; one for the Virtual IP Address AND physical IP Addresses for each array-member. Of course all internal IP Addresses.

    When a DirectAccess Client connects to an internal resource (e.g. Manage-Out Client), NAT is applied from a physical IP Address of one array-member. I don't know if this solves you issue, but just double-check it.


    Boudewijn Plomp, BPMi Infrastructure & Security

    Monday, August 27, 2012 11:37 AM
  • Yes we've an UAG array configuration with two array-members. For each physical IP address and Virtual IP address a ISATAP DNS record are present!

    Ronny de Jong | inovativ.nl | Blog: donnystyle.wordpress.com | Twitter: twitter.com/ronnydejong

    Monday, August 27, 2012 11:46 AM