locked
UAG Direct Access not working through TMG RRS feed

  • Question

  • Hello,

    I am testing UAG and Direct access at work, and so far all is awesome!! When I take a Laptop and a Desktop computer outside of work and plug in into the average home worker router/firewall with broadband, it connects and works spot on. But at my home in my lab, I have a TMG box and everthing goes through there for external access to the Internet etc. But my Laptop and other tested Laptops will not connect with the Direct Access to work about 9 times out of 10, and can't see why?? I have an old IPCOP firewall that is stll there from days past, and when I connect through there it wroks perfect!!

    Can anyone shed and light on what's happening?

     

    Regards


    Many Thanks

    • Edited by dbilbie Monday, October 10, 2011 8:53 AM
    Monday, October 10, 2011 8:51 AM

Answers

  • Probably works when using Teredo, not IP-HTTPS.

    Teredo is the preferred method, but the DA client will fallback to IP-HTTPS if necessary...I am guessing it only fails when the clients fallback...

    Save yourself a lot of heartache/headaches and buy an IP-HTTPS certificate from a public CA like Verisign, GlobalSign etc.

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by dbilbie Thursday, February 16, 2012 10:29 AM
    Wednesday, October 19, 2011 12:27 PM
  • Hi Bilbazafa,

    the URL you've mentioned needs to be accessible externaly.

    In addition i prefer to make this URL unaccessible from the internal network. This will make sure the internal clients simply can't connect to it and therefor rule out some dirty misconfigurations ...

    -Kai

     


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de
    • Marked as answer by dbilbie Thursday, February 16, 2012 10:32 AM
    Wednesday, October 19, 2011 1:12 PM
  • Hi Bilbazafa,

    you have to make sure the IPHTTPS URL is accessible over the internet to use IPHTTPS transition technologies.

    Depending on the SSL certificate you're planning to use, you've also make sure the CRLs are accessible. If the certificate is a public one, the PKI company will take care of it. If its a private CA then you have to make sure the CRLs could be accessed over the internet.

    -Kai

     


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de
    • Marked as answer by dbilbie Thursday, February 16, 2012 10:31 AM
    Thursday, October 20, 2011 12:04 PM
  • Good eye, Arjan. In the output of the teredo show state command the reason that Teredo is not connecting is that "client is in a managed network". Basically this means that your laptop is able to contact a domain controller, and by default Teredo turns itself off when that happens. It is one of my DirectAccess best practices to change Teredo's behavior from "Client" to "Enterpriseclient" for all DA machines. You can do this by running a command line on each machine (netsh interface teredo set state enterpriseclient) or you can change it for all DA machines at once by using a GPO.

    Setting Teredo to Enterpriseclient on your laptop will probably fix your DA connection from home.

    However, you do also appear to have a problem with your IP-HTTPS configuration, and that will cause you more headaches down the road. As already mentioned, anytime that Teredo cannot connect (usually because you are sitting behind a firewall that blocks UDP traffic) then the DA client will fall back to using IP-HTTPS, and in your case will then fail.

    To make things easier on yourself, take Kai's advice and get a public SSL cert for the IP-HTTPS listener. And yes, you should definitely be able to browse to https://gateway.mycompanyname.co.uk:443/IPHTTPS from your DA client machine, and you should receive a 403 error without getting any certificate warning messages first. If you get any other results when you browse to this page, then IP-HTTPS isn't working properly.

    • Marked as answer by dbilbie Thursday, February 16, 2012 10:28 AM
    • Unmarked as answer by dbilbie Thursday, February 16, 2012 10:28 AM
    • Marked as answer by dbilbie Thursday, February 16, 2012 10:32 AM
    Thursday, October 27, 2011 12:17 PM

All replies

  • Hi Bilbazafa,

    to get DirectAccess connectivity behind a Firewall/Proxy (aka. TMG), you have to make sure UDP3544 (Teredo) and/or TCP443 (IPHTTPS) are allowed "Anonymously". Thats all what needed - everything else (e.g. DA Tunnels) will run above these protocols and therefor won't require additional holes in your rule set.

    -Kai


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de
    Monday, October 10, 2011 9:10 AM
  • Thanks Kai I'll give it a go. But why woud it only work hit and miss? I have  rule setup in TMG saying Allow All outbound traffic from Internal to External, All content types and applies to All Users. Should this not cover what you are saying above. Or am I missing something again??

    Kind Regards


    Many Thanks
    • Edited by dbilbie Tuesday, October 11, 2011 12:17 AM
    Monday, October 10, 2011 10:38 PM
  • Hi Bilbazafa,

    the rule you've mentioned should normaly do the trick.

    To help you further we need some additional information of the IPv6 transition technology and IPSec tunnel state(s) when the error arise. So please post the output of these commands...

    CERTUTIL.EXE -STORE MY
    NETSH.EXE DNSCLIENT SHOW STATE
    NETSH.EXE INTERFACE TEREDO SHOW STATE
    NETSH.EXE INTERFACE HTTPSTUNNEL SHOW INTERFACE
    NETSH.EXE NAMESPACE SHOW POLICY
    NETSH.EXE NAMESPACE SHOW EFFECTIVEPOLICY
    

    -Kai

     


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de
    Tuesday, October 11, 2011 10:49 AM
  • You can also consider these steps too:

    When a DA client is in a site that has a proxy the following steps should be taken
     
    1.      Obtain the IP address of the proxy server
    2.      Configure IE to use that proxy server
    3.      Run netsh winhttp import proxy source=ie
    4.      Use DirectAccess
    5.      When you leave the customer site, clear the proxy settings from IE
    6.      Run netsh winhttp import proxy source=ie again (clears proxy settings)

    As you may have gathered, DA clients cannot connect when using an authenticating web proxy.

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, October 12, 2011 9:17 AM
  • Kai, please see below. Thanks

    C:\>CERTUTIL.EXE -STORE MY

    MY

    ================ Certificate 0 ================

    Serial Number: 1ded5c3c0000000000cf

    Issuer: CN=My Company Name

    NotBefore: 06/10/2011 4:33 PM

    NotAfter: 05/10/2012 4:33 PM

    Subject: CN=EXT-LAPTOP04.MyCompanyName.co.uk

    Certificate Template Name (Certificate Type): Machine

    Non-root Certificate

    Template: Machine

    Cert Hash(sha1): 7e 4f f4 f2 b9 f2 af 76 79 88 0f 74 30 5e 03 02 5b 8a 77 09

    Key Container = 083c977a6aa4ac3c4e90ab73e27d62c9_332bc869-55f8-4df1-8ed2-43f00987e961

    Simple container name: le-Machine-00c4559b-f4c3-4589-90a1-474405f1766f

    Provider = Microsoft RSA SChannel Cryptographic Provider

    Private key is NOT exportable

    Encryption test passed

    CertUtil: -store command completed successfully.

    C:\>NETSH.EXE DNSCLIENT SHOW STATE

    Name Resolution Policy Table Options

    --------------------------------------------------------------------

    Query Failure Behavior : Always fall back to LLMNR and NetBIOS

                if the name does not exist in DNS or

    if the DNS servers are unreachable

                when on a private network

    Query Resolution Behavior : Resolve only IPv6 addresses for names

    Network Location Behavior : Let Network ID determine when Direct

                             Access settings are to be used

    Machine Location : Outside corporate network

    Direct Access Settings : Configured and Enabled

    DNSSEC Settings : Not Configured

    C:\>NETSH.EXE INTERFACE TEREDO SHOW STATE

    Teredo Parameters

    ---------------------------------------------

    Type : client

    Server Name : XX.XXX.XXX.X (Group Policy)

    Client Refresh Interval : 30 seconds

    Client Port : unspecified

    State : offline

    Error : client is in a managed network

    C:\>NETSH.EXE INTERFACE HTTPSTUNNEL SHOW INTERFACE

    Interface IPHTTPSInterface (Group Policy) Parameters

    ------------------------------------------------------------

    Role : client

    URL : https://gateway.mycompanyname.co.uk:443/IPHTTPS

    Last Error Code : 0x80092013

    Interface Status : failed to connect to the IPHTTPS server. Waiting to reconnect

    C:\>NETSH.EXE NAMESPACE SHOW POLICY

    DNS Name Resolution Policy Table Settings

    Settings for .edfs.mycompanyname.co.uk

    ----------------------------------------------------------------------

    Certification authority : CN=Mycompanyname

    DNSSEC (Validation) : disabled

    DNSSEC (IPsec) : disabled

    DirectAccess (DNS Servers) :

    DirectAccess (IPsec) : disabled

    DirectAccess (Proxy Settings) : Use default browser settings

    Settings for nls.mycompanyname.co.uk

    ----------------------------------------------------------------------

    Certification authority : CN=My Company Name

    DNSSEC (Validation) : disabled

    DNSSEC (IPsec) : disabled

    DirectAccess (DNS Servers) :

    DirectAccess (IPsec) : disabled

    DirectAccess (Proxy Settings) : Use default browser settings

    Settings for .communication.mycompanyname.co.uk

    ----------------------------------------------------------------------

    Certification authority : CN=My Company Name

    DNSSEC (Validation) : disabled

    DNSSEC (IPsec) : disabled

    DirectAccess (DNS Servers) :

    DirectAccess (IPsec) : disabled

    DirectAccess (Proxy Settings) : Use default browser settings

    Settings for .ppol1.mycompanyname.co.uk

    ---------------------------------------------------------------Certification authority : CN=My Company Name

    DNSSEC (Validation) : disabled

    DNSSEC (IPsec) : disabled

    DirectAccess (DNS Servers) :

    DirectAccess (IPsec) : disabled

    DirectAccess (Proxy Settings) : Use default browser settings

    Settings for gateway.mycompanyname.co.uk

    ----------------------------------------------------------------------

    Certification authority : CN=My Company Name

    DNSSEC (Validation) : disabled

    DNSSEC (IPsec) : disabled

    DirectAccess (DNS Servers) :

    DirectAccess (IPsec) : disabled

    DirectAccess (Proxy Settings) : Use default browser settings

    Settings for .Mycompanyname.co.uk

    ----------------------------------------------------------------------

    Certification authority : CN=My Company Name

    DNSSEC (Validation) : disabled

    DNSSEC (IPsec) : disabled

    DirectAccess (DNS Servers) : 2002:51ab:9a09::51ab:9a09

    DirectAccess (IPsec) : disabled

    DirectAccess (Proxy Settings) : Bypass proxy

    C:\>NETSH.EXE NAMESPACE SHOW EFFECTIVEPOLICY

    DNS Effective Name Resolution Policy Table Settings

    Settings for .edfs.mycompanyname.co.uk

    ----------------------------------------------------------------------

    Certification authority : CN=Mycompanyname

    DNSSEC (Validation) : disabled

    IPsec settings : disabled

    DirectAccess (DNS Servers) :

    DirectAccess (Proxy Settings) : Use default browser settings

    Settings for nls.mycompanyname.co.uk

    ----------------------------------------------------------------------

    Certification authority : CN=Mycompanyname

    DNSSEC (Validation) : disabled

    IPsec settings : disabled

    DirectAccess (DNS Servers) :

    DirectAccess (Proxy Settings) : Use default browser settings

    Settings for .communication.mycompanyname.co.uk

    ----------------------------------------------------------------------

    Certification authority : CN=Mycompanyname

    DNSSEC (Validation) : disabled

    IPsec settings : disabled

    DirectAccess (DNS Servers) :

    DirectAccess (Proxy Settings) : Use default browser settings

    Settings for .ppol1.mycompanyname.co.uk

    ----------------------------------------------------------------------

    Certification authority : CN=Mycompanyname

    DNSSEC (Validation) : disabled

    IPsec settings : disabled

    DirectAccess (DNS Servers) :

    DirectAccess (Proxy Settings) : Use default browser settings

    Settings for gateway.mycompanyname.co.uk

    ----------------------------------------------------------------------

    Certification authority : CN=Mycompanyname

    DNSSEC (Validation) : disabled

    IPsec settings : disabled

    DirectAccess (DNS Servers) :DirectAccess (Proxy Settings) : Use default browser settings

    Settings for .Mycompanyname.co.uk

    ----------------------------------------------------------------------

    Certification authority : CN=Mycompanyname

    DNSSEC (Validation) : disabled

    IPsec settings : disabled

    DirectAccess (DNS Servers) : 2002:51ab:9a09::51ab:9a09

    DirectAccess (Proxy Settings) : Bypass proxy

     


    Many Thanks
    Wednesday, October 12, 2011 10:41 PM
  • Hi Bilbazafa!

    Why technology is this trying to communicate Teredo or iphttps?

    Teredo must have open port UDP 3544

    Iphttps must have port TCP 443 open, now if he is a certified private issued by AD CS must publish the certificate revocation list (CRL) on the internet.

    This not is required for public certificates as they have published the CRL in the internet.

    Best regards
    Carlos Avendaño

    Wednesday, October 12, 2011 11:18 PM
  • Hi Jason,

    This sounds like a ball ache, especially if my users with a Laptop go to a clients that use a proxy. Since they have GPO's locking them out of those functions and I wouldn't be able to get them to do that anyway!

     


    Many Thanks
    Thursday, October 13, 2011 1:47 PM
  • hi Carlos,

    Not quite following you my friend?


    Many Thanks
    Thursday, October 13, 2011 1:47 PM
  • Hi Jason,

    This sounds like a ball ache, especially if my users with a Laptop go to a clients that use a proxy. Since they have GPO's locking them out of those functions and I wouldn't be able to get them to do that anyway!

     


    Many Thanks
    Yeah, dont shoot the messenger ;)
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, October 13, 2011 2:00 PM
  • Defiantly not, really appreciate your help J


    Many Thanks
    Thursday, October 13, 2011 2:05 PM
  • Hi Kai,

     

    Have you taken a look at my data a copied and paste for you?


    Many Thanks
    • Edited by dbilbie Wednesday, October 19, 2011 10:35 AM
    Wednesday, October 19, 2011 10:35 AM
  • Hi Bilbazafa,

    no, i missed to come back to this thread :)

    Well, based on your provided data it seems that both the Teredo and IPHTTPS interfaces are unable to connect to the corresponding servers (i guess its a timeout operation). So there must be still a problem in the TMG rule set which causes the Teredo and IPHTTPS requests getting blocked.

    As i said, both tunnel protocols are needing an anonymous access through your TMG box. To see the reason why TMG blocks the request, you have to use the TMG Log Monitor (home site) and extract the releated log entires for TCP443 and UDP3544 destined to your external DirectAccess IPv4 addresses.

    -Kai


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de
    Wednesday, October 19, 2011 10:46 AM
  • Wait, its not a timeout operation, its the CRL Check which is failing for the IPHTTPS connection! (e.g. Err: 0x80092013)

    So there is an issue with the certificate revocation list of the SSL certificate you're using. Are you using a private certificate or is it a public trusted certificate chain?

    -Kai


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de
    Wednesday, October 19, 2011 10:53 AM
  • Hi Kai,

    It's a Private Certificate. I'm just testing at the moment, is this not good Kai?


    Many Thanks
    Wednesday, October 19, 2011 11:57 AM
  • Hi Bilbazafa,

    well, at least its not recommended to use a private certificate for IPHTTPS since it will make the deployment a little more complex (e.g. CRL checks, AIA trusts, etc.). The additional effort needed to make private certificates usable will make the solution most likely more expensive compared to simply buy a public SSL certificate.

    BTW: For testing porposes (only for that!) i like to recommend you to use self-signed / private certificate which don't have a CRL download location specified. In this case the CRL check for the IPHTTPS certificate will be skipped by the DA clients^^

    -Kai


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de
    Wednesday, October 19, 2011 12:05 PM
  • Thanks Kai,

    Why would it make it more expensive to make a Private Cert usable? Also why would it be working intermittently?


    Many Thanks
    Wednesday, October 19, 2011 12:14 PM
  • Probably works when using Teredo, not IP-HTTPS.

    Teredo is the preferred method, but the DA client will fallback to IP-HTTPS if necessary...I am guessing it only fails when the clients fallback...

    Save yourself a lot of heartache/headaches and buy an IP-HTTPS certificate from a public CA like Verisign, GlobalSign etc.

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by dbilbie Thursday, February 16, 2012 10:29 AM
    Wednesday, October 19, 2011 12:27 PM
  • Hi Bilbazafa,
     
    well, its bacause a public trusted cert won't cost that much money, but deploying/maintaining a private CA which is external accessible will take quite some time to make it right. And since "time" = "$" it will be in 9 of 10 cases more expensive ...

    Regarding the intermittently question. Well, you have to dig into the CRL retrival/validation to get the answer why it sometimes works. I don't know anything about your specific PKI deployment, so i can't tell you what could be the reason. So i can only recommend to take a look to the CRL retrival / validation in the case the problem arise again.

    All you have to make sure is that the client would be able to get a valid and fresh CLR file during IPHTTPS connection establishment. 

    -Kai

     

    • Edited by Kai Wilke Wednesday, October 19, 2011 12:54 PM
    Wednesday, October 19, 2011 12:41 PM
  • Thanks,

    I am I right in saying that this needs to be accessible externally as in public https://gateway.mycompanyname.co.uk:443/IPHTTPS


    Many Thanks
    Wednesday, October 19, 2011 1:04 PM
  • Hi Bilbazafa,

    the URL you've mentioned needs to be accessible externaly.

    In addition i prefer to make this URL unaccessible from the internal network. This will make sure the internal clients simply can't connect to it and therefor rule out some dirty misconfigurations ...

    -Kai

     


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de
    • Marked as answer by dbilbie Thursday, February 16, 2012 10:32 AM
    Wednesday, October 19, 2011 1:12 PM
  • But if I had a Public Cert it wouldn't need to be accessible right?
    Many Thanks
    Wednesday, October 19, 2011 2:31 PM
  • Hi Bilbazafa,

    AFAIK, every Public CA does have their CRL published. Either trough CRLs (Certificate Revocation Lists) and/or through OSCP (Online Certificate Status Protocol). The differece between your internal CA and the public CAs is "just" a pre-established trust and the responsibility for setup/maintaining the services. When using a public CA you won't have to think about making these things accessible, fresh and reliable.

    Using a public CA for IPHTTPS is a thing of "pay the small fee" and "forget the things for the next few years" ...

    -Kai


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de
    Wednesday, October 19, 2011 2:52 PM
  • Hi Kai,

    The URL I mentioned is not accessible externally. Would it need to be whether or not I had a Private or Public Cert?


    Many Thanks
    Thursday, October 20, 2011 10:55 AM
  • Hi Bilbazafa,

    you have to make sure the IPHTTPS URL is accessible over the internet to use IPHTTPS transition technologies.

    Depending on the SSL certificate you're planning to use, you've also make sure the CRLs are accessible. If the certificate is a public one, the PKI company will take care of it. If its a private CA then you have to make sure the CRLs could be accessed over the internet.

    -Kai

     


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de
    • Marked as answer by dbilbie Thursday, February 16, 2012 10:31 AM
    Thursday, October 20, 2011 12:04 PM
  • HI,

    If your other clients and connections are working the issue will be on your local network at home.

    Now I use several test machines from home among which I have a DC on the local net. Teredo will see the DC and will not come up.

    You can change this behaviour by entering: netsh int teredo set state enterpriseclient

    Not that might work for you assuming your external TMG is setup correctly.

    You can check the following link :http://blogs.technet.com/b/tomshinder/archive/2010/12/01/uag-directaccess-and-the-windows-firewall-with-advanced-security-things-you-should-know.aspx

    But keep in mind UDP3544 and TCP443 is not enough. FOr teredo to work you also need some ICMPv6 ports open!

    Check the following link: http://winintro.ru/da_snap.en/html/2f5ff4e1-3c30-434e-9fc1-1d2bea6271be.htm

    Arjan

     

    • Marked as answer by dbilbie Thursday, February 16, 2012 10:28 AM
    • Unmarked as answer by dbilbie Thursday, February 16, 2012 10:28 AM
    Thursday, October 27, 2011 7:17 AM
  • Good eye, Arjan. In the output of the teredo show state command the reason that Teredo is not connecting is that "client is in a managed network". Basically this means that your laptop is able to contact a domain controller, and by default Teredo turns itself off when that happens. It is one of my DirectAccess best practices to change Teredo's behavior from "Client" to "Enterpriseclient" for all DA machines. You can do this by running a command line on each machine (netsh interface teredo set state enterpriseclient) or you can change it for all DA machines at once by using a GPO.

    Setting Teredo to Enterpriseclient on your laptop will probably fix your DA connection from home.

    However, you do also appear to have a problem with your IP-HTTPS configuration, and that will cause you more headaches down the road. As already mentioned, anytime that Teredo cannot connect (usually because you are sitting behind a firewall that blocks UDP traffic) then the DA client will fall back to using IP-HTTPS, and in your case will then fail.

    To make things easier on yourself, take Kai's advice and get a public SSL cert for the IP-HTTPS listener. And yes, you should definitely be able to browse to https://gateway.mycompanyname.co.uk:443/IPHTTPS from your DA client machine, and you should receive a 403 error without getting any certificate warning messages first. If you get any other results when you browse to this page, then IP-HTTPS isn't working properly.

    • Marked as answer by dbilbie Thursday, February 16, 2012 10:28 AM
    • Unmarked as answer by dbilbie Thursday, February 16, 2012 10:28 AM
    • Marked as answer by dbilbie Thursday, February 16, 2012 10:32 AM
    Thursday, October 27, 2011 12:17 PM