Unable to manage DA clients over IPHTTPS connection... RRS feed

  • Question

  • Hi all,

    I have a problem where I cannot manage clients over the IPHTTPS tunnel. Teredo works fine, however if both are up (or just the IPHTTPS) then I cannot manage via DNS (as everything seems to default to the IPHTTPS entry). Hope that makes sense. Happens on any client and from any of our "Management Servers" - so it's causing us SCCM problems. We are using UAG SP1 in a 2 node array.


    I have done some troubleshooting and have run out of ideas - below is a list of what I have covered (all testing is done with the teredo tunnel disabled via netsh as otherwise the IPHTTPS tunnel eventually disconnects and everything works);


    "Main Mode" Security Associations in WFAS - I can see several of these listed (2 x Kerberos and 2 x NTML) so I know the Inf and Int tunnels are being brought up - however unusual point here is that the "established" tunnels seems to be for the IPV6 "Temporary" IP address of the IPHTTPS adapter. There is a "preferred" address - this is what is registered with DNS. The "Temporary IP" seems to be none-reachable pinging it gives "cannot find host" rather than a time out?). I suspect this may have something to do with the problem, though I have no other site to compare to ATM.


    Pings work to/from server/client - so I know the Inf tunnel is brought up.


    However anything else doesnt - RDP/Telnet (with server installed/running). I have created firewall rules as per Tom's postings - and then extended them widely to not only accept RDP from "any" source - but also have a blanket "allow anything from anywhere" rule in. No help.


    Network Monitor capture is a little strange. If I run one from UAG02 to the client and attempt an RDP I see the AuthIP negotiation then everything becomes encrypted (ESP). Client shows the same - so UAG02 is able to route something down the IPHTTPS tunnel. However if I then attempt to recplicate this from a DC I get different results - the DC sends the RDP request to the ISATAP DNS entry (secondary IP on UAG02) then sends the same request via IPV6 to the client's Preferred IPV6 address - UAG never replies and neither does the client. I get about 3/4 re-sends then it bombs out. Client see's nothing of this - so I can only presume that UAG isn't happy passing the traffic on.


    Have enabled Audit logging on both UAG servers - nothing unusual that I can see there.


    It's almost as though the client is happy bringing the tunnel up on the temp IP as is UAG - and it just never "changes" to the preferred IP..?


    Thanks for any help in advance, I'm stumped with this one! :(



    Wednesday, October 5, 2011 9:19 AM

All replies

  • Don't worry too much about the IP-HTTPS temporary IP address showing up in the Security Associations, my own laptop is running IP-HTTPS right now and I also have the temporary addresses listed in my SAs, yet when I ping my client from a server inside the network it replies from my "real" IP. Also, RDP to my laptop is working.

    When you are testing these WFAS rules to allow the communications, are you creating the rules and assigning them via GPO or are you creating them manually in WFAS? Creating the rules by hand in WFAS is flaky at best, don't ask me why but I have had numerous occasions where during an install I test this out with rules that I created directly on the laptop and it didn't work, but as soon as I created a GPO that included the exact same rules, they worked great.

    Wednesday, October 5, 2011 12:45 PM
  • Yes, the WFAS rules are applied via a GPO - the test client/user I have is restricted and cannot edit them anyway (and "working around" to do so kicks me from NAP).


    I am leaning away from the temp IP now - as I can contact this via Ping but (again) not via RDP. I was only concerned as occaisionally I was seeing a stage 1 Security Association but no stage 2 for the none-temp IP (all the time whilst seeing stage1 + 2 for the temp IP)


    Also I am convinced it is not local firewall - if I force two clients onto IPHTTPS connection then they can RDP between each other - so the local firewall rules are working.
    Wednesday, October 5, 2011 2:06 PM
  • Have you tried (just temporarily of course) creating an "allow 3389, from all, to all" rule via GPO to test it and see if it works then? Make sure you allow Edge Traversal on that rule as well. When you say it works between IP-HTTPS clients but not from the corporate network, the first thing that comes to mind is that the ISATAP prefix (assuming you're using ISATAP) may not be populated properly in the firewall rule.
    Wednesday, October 5, 2011 8:43 PM
  • I have three rules in via GPO - both tried one at a time and all;


    RDP from specified source (managment servers)

    RDP from all sources

    Anything from all sources (if you wish, an "any any" rule)


    None of which help - yet I know it is allowing traffic as other clients can contact on RDP (well, I had a funny one before - a client could be contacted via RDP but couldnt reach out on RDP. Difference was this one required patching to become NAP compliant - so it only brought up the inf tunnel and got placed in remediation. I will ignore this for now, unless someone things it important)


    we are using ISATAP and UAG is being used as an ISATAP router. A packet capture see's ISATAP-enabled management servers heading to the ISATAP router first then attempting a connection to the client via IPv6 - UAG see's this too but never sends it to the client (as the client is stupidly silent on a packet capture at this stage).


    Thanks for the suggestion though Jordan! :)


    Wednesday, October 5, 2011 8:51 PM
  • Also, to clarify, I have enabled logging on the client firewall - it shows no dropped packets when I attempt an RDP so I can only presume the attempts never get there :(
    Wednesday, October 5, 2011 9:51 PM
  • I have since rebuilt the Firewall GPO (there were some strange entries within there) - to no avail. ICMP traffic still goes through but even when configured not to drop incoming packets I still cannot RDP to the client!
    Friday, October 7, 2011 11:24 AM
  • What happens if you specifically disable Teredo on the DA client, so you enfore IP-HTTPS?
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: and
    Friday, October 7, 2011 1:31 PM
  • Ironically enough this is how I'm having to test it most of the time as leaving both Teredo and IPHTTPS up eventually downs the IPHTTPS tunnel and then it all works.


    Interesting thing found out though - if I change the "Exclude ICMP from IPSEC" to "No" then I can no longer ping. It's almost as though UAG refuses to pass IPHTTPS Intranet tunnel traffic from UAG to the Client.


    Saturday, October 8, 2011 10:06 PM