DirectAccess "An IPsec main mode negotiation failed." RRS feed

  • Question

  • Hello everyone,   I've spent a lot of time trying to get a DirectAccess implementation off the ground, but I've been stuck on a problem with the infrastructure tunnel for a long time now.  From my troubleshooting I have more or less pinpointed where the problem is, I just haven't been able to figure out the solution. I'm pretty sure it's a problem with IPSec and/or my certificate configuration.  Just a quick run through of my troubleshooting steps:

    1) The IPHTTPS interface is established when running netsh interface httpstunnel show interfaces

    2) netsh namespace show effectivepolicy shows the correct configuration for intranet DNS, and NLS… although IPSec appears as “disabled”.

    3) IPv6 address of the DNS server from the aforementioned command replies to ping.

    4) DNS resolutions sent to the aforementioned IPv6 address time out

    5) wf.msc > "Monitoring" > "Connetion Security Rules" shows DirectAccess rules applied, however DirectAccess Policy-ClientToDnsDc that I have heard about is missing?

    6) wf.msc > "Monitoring" > "Security Associations" > “Main Mode” is completely blank

    7) Event Viewer has a bunch of logs titled “An IPsec main mode negotiation failed.

    From what I've read, IPSec failures for DirectAccess are usually caused by certificate configuration.  I'm not sure how to troubleshoot this as my SSTP VPN connection hosted on another server works fine... this includes publishing of the CRL to an internet accessible location.  I have been getting mixed message from the internet on which certificate templates should be used for DirectAccess ... but right now I have separate templates for DirectAccess Client and DirectAccess Server.  Both include intended purposes for "Server Authentication", "Client Authentication", and "IKE security IKE intermediate"

    Any thoughts?  I appreciate any information, or further troubleshooting steps you guys can provide!

    Thursday, November 16, 2017 8:35 PM

All replies

  • Bump?  
    Tuesday, November 21, 2017 2:49 PM
  • I ran the Microsoft DirectAccess Troubleshooting Tool, but it didn't provide any additional information to what I already know... just reaffirmed that the problem lies somewhere around the IPSec step of the infrastructure tunnel.

    Tuesday, November 21, 2017 3:11 PM
  • You are correct that the trouble lies with your IPsec tunnels not building, and that is generally caused by something not working properly with the certificates. Your Connection Security Rules in WFAS look good, by the way. Also, IPsec showing as "disabled" inside the NRPT rules is normal behavior.

    You don't have to use different templates for the client and server, but as long as they both chain up to the same root it should be sufficient - and make sure that root CA is the one specified inside the Authentication screen of Step 2 of the DA config wizards.

    It is also worth checking over the DisabledComponents regkey, just to make sure it doesn't exist or isn't interfering in any way:

    (as you can see in this post, you can either make sure DisabledComponents is non-existent, or use it as 0x10. Basically you just want to make sure it isn't set to anything other than one of those two values)

    Is this a dual-NIC DA server? If so, it would be important to check over routing and make sure all of the static routes are in there correctly so that the internal traffic is pushing through the internal NIC, a lack of routes or NICs configured improperly (in a dual-NIC system you never have a Default Gateway on the internal NIC) could cause a similar behavior to what you are seeing.

    Thursday, December 7, 2017 2:37 PM
  • Did you ever get a fix to this as I'm seeing the same issue.
    Tuesday, January 22, 2019 12:26 AM
  • I never heard more on this particular case, there were a few possibilities for what could have been the culprit. If you're in the middle of it and want to chat back and forth about it offline, feel free to reach out here:
    Tuesday, January 22, 2019 9:04 PM