none
UAG DirectAccess - no DNS or connections to intranet, suspect IPSec issue RRS feed

  • Question

  • Hi,

    I have a problem with DirectAccess on UAG, clients can ping DA and internal serveres, but I can't get any other connections, even DNS fails.
    I checked the thread http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/a679f007-4daa-4cfb-88bb-21f958c3d383, but that did not help me.

    DA server's external NIC is in DMZ, all ports and protocols opened according to doc.
    We're using public IP's internally (different subnet from external public IP's)
    The client can connect on Teredo and IPHTTPS.
    Since we have some older integration software we cannot upgrade domain controllers til 2008 or 2008 R2 yet, so I rely completely on DNS64.
    NRPT OK.
    When I check the main mode connections I don't see any kerberos connections, only ntlm, so I suspect something with IPSec/Certificates:
    Main Mode SA at 02/11/2010 14:59:57
    ----------------------------------------------------------------------
    Local IP Address:                     2002:xxxx:xxxx::xxxx:7d10
    Remote IP Address:                    2002:xxxx:xxxx:8100:xxxx:xxxx:xxxx:f275
    Auth1:                                ComputerCert
    Auth2:                                None
    MM Offer:                             None-AES128-SHA256
    Cookie Pair:                          d90b129f8eaa0fb1:27d67b150d8e272c
    Health Cert:                          Yes

    Main Mode SA at 02/11/2010 14:59:57
    ----------------------------------------------------------------------
    Local IP Address:                     2002:xxxx:xxxx::xxxx:7d10
    Remote IP Address:                    2002:xxxx:xxxx:8100:xxxx:xxxx:xxxx:f275
    Auth1:                                ComputerCert
    Auth2:                                UserNTLM
    MM Offer:                             None-AES128-SHA256
    Cookie Pair:                          c723d43b1b4a6d23:b211f779320ea48d
    Health Cert:                          Yes
    Ok.


    Quick Mode SA at 02/11/2010 15:00:30
    ----------------------------------------------------------------------
    Local IP Address:                     2002:xxxx:xxxx::xxxx:7d10
    Remote IP Address:                    2002:xxxx:xxxx:8100:xxxx:xxxx:xxxx:f275
    Local Port:                           Any
    Remote Port:                          Any
    Protocol:                             Any
    Direction:                            Both
    QM Offer:                             ESP:SHA1-AES192+60min+100000kb
    PFS:                                  None

    Quick Mode SA at 02/11/2010 15:00:30
    ----------------------------------------------------------------------
    Local IP Address:                     2002:xxxx:xxxx::xxxx:7d10
    Remote IP Address:                    2002:xxxx:xxxx:8100:xxxx:xxxx:xxxx:f275
    Local Port:                           Any
    Remote Port:                          Any
    Protocol:                             Any
    Direction:                            Both
    QM Offer:                             ESP:SHA1-None+60min+100000kb
    PFS:                                  None
    Ok.

    Both DA server and client certificates come from the same CA, and works for all other purposes.
    We also use NAP (in monitoring mode), so the DA server and client also has health certificates from the NAP CA, which is a subordinate CA to the "normal" CA.

    Any suggestions?


    David
    Thursday, February 11, 2010 2:55 PM

Answers

  • The problem was related to incorrect NAP configuration, the server was requesting root cert, while client was requesting intermediate.

    I can't wrap my head around why this would break DA since NAP was running in monitoring mode, and I had not enabled NAP for the infrastructure tunnel, but at least everything works now.

    Thanks!
    David
    • Marked as answer by David Rukavina Friday, February 12, 2010 12:56 PM
    Friday, February 12, 2010 12:55 PM

All replies

  • Hi David,

    Work your way through this:

    http://technet.microsoft.com/en-us/library/ee624056(WS.10).aspx

    this specifically for your case I think:

    http://technet.microsoft.com/en-us/library/ee844114(WS.10).aspx

    Perhaps CRL issues from the UAG server?

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd
    Thursday, February 11, 2010 3:31 PM
    Moderator
  • Hi, thanks for replying so quickly!

    CRL is ok (can download with browser internally and externally), and I don't believe the IP-HTTPS tunnel could be established otherwise.

    Reading through the links (again), I noticed one thing - The main and quick mode SA's that do get established point to the second of the two consective IP addresses. The doc states that the infrastructure tunnel should point to the first IP, and the intranet tunnel to the second IP. And looking at the auth methods, those SA's have to be the infrastructure tunnel..

    I'm unable to investigate any further today, will continue tearing my hair out tomorrow :)

    David
    Thursday, February 11, 2010 4:50 PM
  • Does the CRL work specifically from the UAG server itself?
    Jason Jones | Forefront MVP | Silversands Ltd
    • Proposed as answer by Erez Benari Thursday, February 11, 2010 11:03 PM
    Thursday, February 11, 2010 9:25 PM
    Moderator
  • The problem was related to incorrect NAP configuration, the server was requesting root cert, while client was requesting intermediate.

    I can't wrap my head around why this would break DA since NAP was running in monitoring mode, and I had not enabled NAP for the infrastructure tunnel, but at least everything works now.

    Thanks!
    David
    • Marked as answer by David Rukavina Friday, February 12, 2010 12:56 PM
    Friday, February 12, 2010 12:55 PM
  • Hi David,

    Work your way through this:

    http://technet.microsoft.com/en-us/library/ee624056(WS.10).aspx

    this specifically for your case I think:

    http://technet.microsoft.com/en-us/library/ee844114(WS.10).aspx

    Perhaps CRL issues from the UAG server?

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd

    Hi Jason,
    When I see the intranet tunnel fail, I don't think of CRL problems so much because we do a weak CRL check for IPsec and computer certificates. So, even if the CRL is not available, it won't cause a problem. What is does point to is a Kerberos issue. So, I'd make sure that all the services are running on the UAG server, that DNS has the IPv4 and IPv6 addresses in DNS, and perhaps restart the UAG server and the DC, as well as the client.

    HTH,
    Tom
    MS ISDUA Anywhere Access Team
    Friday, February 12, 2010 12:57 PM
    Moderator
  • Thanks Tom!
    Jason Jones | Forefront MVP | Silversands Ltd
    Friday, February 12, 2010 1:07 PM
    Moderator
  • Hi Jason,

    Keep in mind that CRL checks are only important for two situations:

    * When connecting to the Network Location Server
    * When connecting to the IP-HTTPS listener

    CRL check isn't an issuing when establishing the IPsec tunnels.

    HTH,
    Tom
    MS ISDUA Anywhere Access Team
    Friday, February 12, 2010 1:27 PM
    Moderator