Manage Out works with ICMP but nothing else RRS feed

  • Question

  • Wierd scenario going on here.


    Single UAG Server with DirectAccess configured and working properly. Configuring Manage Out capabilities I can ping DirectAccess clients from internal computers successfully. Using tracert I see the traffic routing through the UAG server acting as a ISATAP router. All is well. When I try RDP or other listeners it just doesn't communicate with the DirectAccess client. I have created WFAS rules, allowing Edge Traversal and I have tried limiting the scope and allowing ANY communication in the scope. Same results either way, connection time out. As soon as the computer is internal and off DirectAccess RDP works perfectly.


    What am I missing?

    Steve Angell - IDA Consultant (http://www.InfraScience.com)
    Friday, October 14, 2011 12:52 AM

All replies

  • Hi,

    Yes I did see the same when we tried this. There is a small catch here that took me some time to figure out.

    First you mentioned that the Windows Firewall rules are set. That has to be in place yes, at least for the teredo connected clients the EDGE Traversal fw rule needs to be there.

    Secondly the machine that needs to connect to the DA client needs to have an ISATAP address.

    From what I read, you have covered this all as you can use ICMP to get to the client.

    But then manage-out in our setup (multi-site with external ISATAP) only works when the machine that initiates the connection is defined as a DA Management machine. Meaning it needs to be able to use the infrastructure (always on) tunnel. You will need to add it via the DA wizard as one of the infratructure machines and re-create the policy and reactivate. This will put the management machine traffic into the infrastructure tunnel.

    It seems only this tunnel is di-directional.

    A related post you can find here: http://blogs.technet.com/b/edgeaccessblog/archive/2009/11/17/deep-dive-into-uag-directaccess-manage-out-basics.aspx

    If you can get manage-out working via the normal user tunnel, please let me know!


    Friday, October 14, 2011 7:24 AM
  • Hi,

    Yes, when using manage-out only the Intranet tunnel is not created/established.
    That means that all systems that should be able to reach the client needs to be specified during the configuration.

    This is the same if you want to reach a machine that does not have a logged on user in a "normal" setup.

    Read the section "Manage Only" in http://blogs.technet.com/b/edgeaccessblog/archive/2010/11/14/uag-2010-sp1-directaccess-always-managed-amp-managed-only.aspx

    A good way to see this for yourself is to look on the IPSec rules found in the Windows Firewall console. (wf.msc)
    With a manage out only setup you will see a rule for the Infrastructure tunnel but none for the Intranet tunnel.

    Best wishes,
    Jonas Blom

    Friday, October 14, 2011 8:52 AM
  • Thanks for the response, and all valid points. However each of these have been address and still no luck.

    The computer I am attempting to connect to a DA client is configured as a Management Server in the DA config on the UAG server. The computer also has an ISATAP address. I have tried connecting by IPv6 address to the DA client as well using both the Infrastructure Tunnel and the Intranet tunnel, both are unsuccessful for all but ICMP.


    One additional note and maybe this will help. Using a sniffer on the DA client I have looked at the traffic coming from the UAG server to the client. When pinging the DA client from an internal server I see ICMP traffic on the DA client that originated from teh UAG server's external interface/ However, when I attempt to RDP from the saem internal server to the DA client the traffic I see is everyting BUT RDP. The traffic is labled as ISAKMP ans ESP but no 3389 traffic. Once I kill the RDP connection attempt the traffic stops, so I know this is traffic originating from the internal server.


    Arjan, you mentioned that Manager Computer being added to the Infrastructure tunnel. Are there additional WFAS Connection Security Rules that should be applied to the  Management Server? The server I am attemtping to manage out has none so I am wondering if this could be an issue.

    Steve Angell - IDA Consultant (http://www.InfraScience.com)
    Saturday, October 15, 2011 12:03 PM
  • Hi sangellga,

    Try enabling logging of both allowed and dropped packets in WFAS to see if/that the RDP traffic reaches the client computer as it should.

    Regarding the ESP/ISAKMP this is related to the IPSec traffic for the IPSec tunnels.
    (ISAKMP is auth/key exchange and ESP is the encrypted data)

    Regarding the part that ICMP is working is a good hint that something isn't working with the IPSec tunnels.
    During the setup it is configured in the UAG DA GPO's to exempt ICMP from beeing sent through the IPSec tunnels.

    You can check it yourself if you look at the Client or Gateway GPO in the following place:

    Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Firewall with Advanced Security -> Global Settings
    Check for "IPSec exempt"

    Best wishes,
    Jonas Blom

    Sunday, October 16, 2011 7:55 PM
  • I have verified that IPSEc is expempt in Global Settings.


    After enabling Allow and Dropped logging in WFAS, I attemped RDP from a Management Server and all I see in the log are allow activity ports 500, 135 and 136. I never see the RDP traffic allowed or dropped.


    Any suggestions?


    Steve Angell - IDA Consultant (http://www.InfraScience.com)
    Sunday, October 16, 2011 9:01 PM
  • Ok, after researching logs and enabling logs for IPSec I am able to find an Event ID 4984 "An IPSec extended mode negotiation failed" 

    Failure point "Remote Computer

    Failure Reason "IKE Negotiation credentials are unacceptable"


    This was capured on the DA client.


    I have verified the certificate for clients and the UAG server are for Server Authentication and Client Authentication OIDs. The only thing different about this deployment and others that I have completed is that the IP-HTTPS certificate for DirectAccess was provided by a third party. Other installations have used a certificate from the internal CA and a web published CRL for the CA.

    Everything is working fine from the client to the internal resources. this error is generated when attempting to connect to a DA client from a Management Server.

    Steve Angell - IDA Consultant (http://www.InfraScience.com)
    Monday, October 17, 2011 1:21 AM
  • Hi,

    The part about using a 3rd party cert for IPHTTPS is only a good change so keep to that :)

    Might be good to look at the security rules then to verify that the correct IPs are listed.

    If you look at the Connection Security Rule named "UAG DirectAccess Client - Clients Access Enabling Tunnel - All" on your test client.
    Can you verify that the IPv6 (ISATAP) address that you connect from internally is listed within the list of IPs in Endpoint 2?
    Also check that the IP is listed in the security rule on your UAG server, here it should be the same name for the rule but the IPs should be listed in Endpoint 1 instead.

    Sorry about my post earlier, see now that you newer talked about manage out only.

    Best wishes,
    Jonas Blom

    Monday, October 17, 2011 6:39 AM
  • No problem Jonas, I appreciate your assistance as this is driving me nuts!


    Checked both security rules and the IP of the server/s I am testing with are listed both on the Server and Client rules.

    I also noticed last night that I am getting a warning in Web Monitor when looking at the DirectAccess connections that states "A client certificate was not provided" This is odd since all connections work from the client side. I have tested 6to4, Teredo and IP-HTTPS connections and all operate normally. When looking at certificates both on the clients and servers no certificate errors are present either. This is a new CA that was stood up as part of this DirectAccess deployment. Not sure if the two are related but just throwing this out there.

    Steve Angell - IDA Consultant (http://www.InfraScience.com)
    Monday, October 17, 2011 11:33 AM
  • Regarding the "A client certificate was not provided", I have seen that around also and seen other posts about it here in the forums.
    Shouldn't be anything to worry about...

    Some more questions to look through then..

    Do you get any corresponding information from the IPSec logging on the UAG server when you see the error on the client?

    I assume you have tried reaching the client from other machines also? (A DC for example)
    Try with something other than RDP (browsing c$ for example)

    Regarding your new CA,
    Check through the CAPI2 log of the client also for warnings/errors.
    Where is the CRL for this new CA published, is it reachable by the client?
    (You're terminating the IPSec tunnels on the UAG right?)


    //Jonas Blom

    Monday, October 17, 2011 12:12 PM
  • I have tried from a few different internal systems as well as different applications, results the same.


    Regarding the CA, the default LDAP CRL is all that has been configured. I can enable publishing of the CRL to the default local CertEnroll site but have not done so at this point. Do I have to do anything to enable the CAPI2 log other than "Enable Logging" in Event Viewer? Never used this log before.


    I am not using End to End Encryption. IPSec terminates at UAG.



    Steve Angell - IDA Consultant (http://www.InfraScience.com)
    Monday, October 17, 2011 12:23 PM
  • No, the CAPI2 log will get all logs related to certificates on the system where the log is enabled.

    So basically enable the logging and then reboot the client and then go through the log efter it has tried to establish the IPHTTPS tunnel.

    (Or disable the network, clear the log and activate the network again and then wait until it tries to reestablish the IPHTTPS interface)




    Monday, October 17, 2011 12:47 PM
  • Ok, found something rather odd.


    The client posts an Event ID 41 stating that "The certificate is not in the revocation server's database" and references the computer certificate on the client PC and the internal CA that issued the certificate. Not sure what could be causing this.


    I have verified that I can browse to the CRL files on the CA from the client PC using windows explorer.

    Steve Angell - IDA Consultant (http://www.InfraScience.com)

    Monday, October 17, 2011 1:42 PM
  • Hm ok,

    Use certutil to verify that everything works.

    certutil –t 30 -f –urlfetch -verify [FilenameOfCertificate]

    certutil -url [FilenameOfCertificate]


    A good link with basic CRL checking:


    I often add a HTTP based publication in the CDP / AIA since that is a type of traffic that works best.

    Still shouldn't be a problem in your case since the IPSec tunnels apparently can be established (access from the client and in works)


    Best wishes,
    Jonas Blom


    Monday, October 17, 2011 7:08 PM
  • Thank you Jonas. I should have clarified just how I verified that I could browse the CRL from the client. Here are the outputs from certutil: (I did a find replace Customer Name with Contoso) to protect the innocent) :)

        EMPTY (DNS Name=CCC-Win7.Contoso.loc)
    Cert Serial Number: 1f3b559a000000000011

    dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
    dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
    ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN (0x20000000)
    -------- CERT_CHAIN_CONTEXT --------
    ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

    SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

    CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
      Issuer: CN=Contoso-CA, DC=Contoso, DC=loc
      NotBefore: 10/13/2011 7:57 PM
      NotAfter: 10/11/2016 7:57 PM
      Serial: 1f3b559a000000000011
      SubjectAltName: DNS Name=CCC-Win7.Contoso.loc
      Template: Contoso Computer
      4a d2 c0 88 7a d5 e2 65 ce 3a 13 81 df 8c 0c 92 a3 05 12 a2
      Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      ----------------  Certificate AIA  ----------------
      Verified "Certificate (0)" Time: 0
        [0.0] ldap:///CN=Contoso-CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Contoso,DC=loc?cACertificate?base?objectClass=certificationAuthority

      ----------------  Certificate CDP  ----------------
      Verified "Base CRL (2b)" Time: 0
        [0.0] ldap:///CN=Contoso-CA,CN=CONCA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Contoso,DC=loc?certificateRevocationList?base?objectClass=cRLDistributionPoint

      Verified "Delta CRL (2b)" Time: 0
        [0.0.0] ldap:///CN=Contoso-CA,CN=CONCA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Contoso,DC=loc?deltaRevocationList?base?objectClass=cRLDistributionPoint

      ----------------  Base CRL CDP  ----------------
      OK "Delta CRL (30)" Time: 0
        [0.0] ldap:///CN=Contoso-CA,CN=CONCA,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Contoso,DC=loc?deltaRevocationList?base?objectClass=cRLDistributionPoint

      ----------------  Certificate OCSP  ----------------
      No URLs "None" Time: 0
        CRL 2b:
        Issuer: CN=Contoso-CA, DC=Contoso, DC=loc
        c3 4f 3f e3 86 b1 47 ea 58 4b d7 ae 97 7b 81 d8 4b 37 62 58
        Delta CRL 30:
        Issuer: CN=Contoso-CA, DC=Contoso, DC=loc
        c6 f1 d1 bf 1e 33 67 51 39 ef 0c e3 72 69 56 93 b8 8f 23 ee
      Application[0] = Server Authentication
      Application[1] = Client Authentication

    CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0
      Issuer: CN=Contoso-CA, DC=Contoso, DC=loc
      NotBefore: 8/31/2011 1:07 PM
      NotAfter: 8/31/2031 1:17 PM
      Subject: CN=Contoso-CA, DC=Contoso, DC=loc
      Serial: 2593584f8cfca8b447da0d0ed4d815a5
      f0 8f 0e 60 cf 6a c3 f7 34 e6 00 c3 09 12 92 d9 d2 69 f8 e4
      Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
      Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
      Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
      ----------------  Certificate AIA  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate CDP  ----------------
      No URLs "None" Time: 0
      ----------------  Certificate OCSP  ----------------
      No URLs "None" Time: 0

    Exclude leaf cert:
      14 07 05 27 19 d5 3d cf 82 6b 22 59 8c c1 6e 1b 6f 24 f7 08
    Full chain:
      03 46 5b 73 e4 6f 32 d8 4e 4a 88 ea 7d bd 39 23 10 06 9c 08
    Verified Issuance Policies: None
    Verified Application Policies: Server Authentication Client Authentication
    Leaf certificate revocation check passed
    CertUtil: -verify command completed successfully.

    The URL check shows the same.

    I have opened a ticket and will post waht the issue is if found but if you have any additional thoughts please post them as I am really out of ideas.


    Steve Angell - IDA Consultant (http://www.InfraScience.com)
    Monday, October 17, 2011 7:46 PM
  • Still have not been called back on my open ticket but in continued research I have found additional errors. If anyone has an idea what might cause these please offer suggestions.

    In the Security Events I found Event ID 4957 Windows Firewall did not apply the following rule.

    The rule is related to CoreNet-IPHTTPS-IN. Error information = Local Port Resolved to an Empty Set

    Also, because of this I ran certutil -t 30 -f -urlfetch -verify on the IPHTPS certificate. When ran on the UAG server everything is fine. When I run it on the DA client I get the following at the end of the output:

    ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)
    CertUtil: The revocation function was unable to check revocation because the revocation server was offline.


    When using the URL retrieval tool the status is verified for all.

    Steve Angell - IDA Consultant (http://www.InfraScience.com)
    Wednesday, October 19, 2011 3:12 PM
  • Actually, found the cause of this error. The DA client I was using was missing an Intermediate 3rd party CA from its trusted authorities. Did not correct my Manage Out issue but did resolve the Verification error shown above.
    Steve Angell - IDA Consultant (http://www.InfraScience.com)
    Wednesday, October 19, 2011 5:02 PM