none
DirectAccess 2012 - An IPsec main mode negotiation failed. RRS feed

  • Question

  • I am working with a customer to deploy DirectAccess 2012 and am running into IPSec issues. The customer has a working UAG DirectAccess configuration using the same PKI as DirectAccess 2012. On both the client and the DA 2012 server I am seeing Event ID 4653 errors every time the client tries to establish a main mode tunnel. I have validated the DA Server configuration. IP-HTTPS cert is a 3rd party cert, the certificate defined for DirectAccess is the root certificate of the local Certificate Authority. Basically, everything is configured the same as the UAG server and using the same certificates but the connection is never being established due to the 4653 errors.

    Any ideas what could be causing this?


    Steve Angell - IAM Practice Director http://www.InfraScience.com)

    Monday, September 22, 2014 11:37 AM

All replies

  • Couple of questions to start with:

    - Clients are Win7, Win 8 or both?

    - Have you limited access to IPHTTPS?

    - Is the 3rd party IPHTTPS certificate chain correct (some 3rd party certs require that you install new intermediate certs)?

    - Any other events? Does the Remote Management console report any other issues?

    - Any other events?

    To doublecheck things, have a look at these threads as they contain most basic TS-steps

    http://social.technet.microsoft.com/forums/forefront/en-US/c3166c43-7821-4ffc-a20e-c143b5e137e0/directaccess-ipsec-main-mode-4653-errror

    http://social.technet.microsoft.com/Forums/en-US/24ac8d55-9c1f-4d38-9ba8-7458f4b9cd7e/directaccess-problems-on-2012-rtm


    Hth, Anders Janson Enfo Zipper

    Monday, September 22, 2014 12:30 PM
  • Hi There - have you tried the troubleshooting guide - http://technet.microsoft.com/en-us/library/ee844114(v=ws.10).aspx ? Is the config exactly the same as the UAG (consecutive public IP's?) - what clients are you running ? - sounds as if the Computer Certs are not as expected - perhaps double check then or perhaps reissue to one client (and new DA Server) and test. 

    Kr


    John Davies

    Monday, September 22, 2014 12:31 PM
  • Thank you, both Win7 and Win8 clients are failing to establish IPSec. I have tried limiting to only IP-HTTPS and it made no difference. Console states all is working correctly. The IPHTTPS cert is 3rd party and the chain has been validated. I will read the other threads to see if something jumps out at me.

    Steve Angell - IAM Practice Director http://www.InfraScience.com)

    Monday, September 22, 2014 5:49 PM
  • I have been through the TS guide and no issues were identified. The config is not the same as UAG, there is only a single IP on the external interface, it is mulithomed. The computer certs are issued from the same template that is issuing certs for the working instance of DirectAccess on UAG. Are you aware of any differences in certificate requirements between UAG and Server 2012 for DirectAccess? I was not aware of any.

    Steve Angell - IAM Practice Director http://www.InfraScience.com)

    Monday, September 22, 2014 5:51 PM
  • Hi Steve - Differences are that UAG required ISATAP or Managed ISATAP where as DirectAccess 2012 specifically states not to use it and use Native IPv6 (or if you need any help with that drop me an email).

    For reference UAG Pre-reqs - http://technet.microsoft.com/en-us/library/dd857262.aspx

    For reference DA 2012 - http://technet.microsoft.com/en-us/library/dn464273.aspx (note ISATAP Section)

    With regards Certs - DA Server requires Computer Certificate Issued by PKI. DA Clients require Computer Cert issued by PKI. DA Server also requires (it is better for 3rd Party to be used) as a IP-HTTPS Cert (or an internal PKI Issued).

    I have seen instances where the DA Server and Client have multiple Computer Certs and causes issue. On the Server ensure there is only one and the Public Cert. On one client ensure that there is only one Computer Cert. Re-test. Also bear in mind that a Win8 Client would be better as it does not check the CRL, whereas the Win7 Client will.

    Kr


    John Davies

    Monday, September 22, 2014 6:25 PM
  • Note that the ISATAP section mostly applies to outbound traffic in a regular DA deployment. It is not very wise to deploy ISATAP internally and use that as the method for communicating from a DA client to internal resources. Server 2012 inherited NAT64 and DNS64 from UAG so there's no need to deploy ISATAP in order to access internal resources.

    Having said that, ISATAP or no ISATAP, you should be able to establish a DA connection without error. The next step would be to see if you actually can access internal resources which is where NAT64 and DNS64 and any deployment of ISATAP would come into play.

    If nothing jumps out from the links I provided, you need to turn on auditing on both client and server as described in the links. Also verify that CAPI2 logging is enabled and see what you find in that log.

    If the MM negotiation fails I would say that you should carefully verify that the certificates used for this from the internal PKI are correct.


    Hth, Anders Janson Enfo Zipper

    Tuesday, September 23, 2014 8:16 AM
  • Thanks for the comments all. I did know the differences regarding ISATAP. What I was trying to say was that as related to client configuration and ability to establish a connection to the server, I was not aware of any major differences such as for certificate requirements.

    I did find the issue yesterday. Someone had decided to get cute with a GPO. I had instructed that the Firewall had to be enabled for DA to work and after some arguement the customer enabled the firewall. However, they then set the Domain and Public firewall profile to "Off". This allowed the Connection Security Rules to be built and displayed but did not allow them to actually work to establish the IPSec tunnel. As soon as this was corrected everything started working as it should. SMH


    Steve Angell - IAM Practice Director http://www.InfraScience.com)

    • Proposed as answer by Vasu Deva Wednesday, October 1, 2014 3:40 PM
    Wednesday, September 24, 2014 2:31 PM