I’ve been working on a Direct Access deployment for quite some time now. The clients are Windows 7 SP1 and the DA servers are based on Windows Server 2012. We hand out DA capabilities using a GPO that is scoped to a Windows Active Directory group. Once the computer is in the group, both the DA settings are configured (GPO) and the client requests a computer certificate (auto-enrollment). From this point on, most of the clients have DA connectivity immediately.
Ironically, while creating a document for the helpdesk to be able to resolve basic DA connectivity issues, I ran into the following issue:
netsh dns show state
DA is configured and is enabled as to be expected…
ipconfig
Our IPHTTPS interface has a valid IP Address. I can even ping the IPv6 address of the DA DNS service (determined by netsh namespace show policy)…
netsh int httpstunnel show int
The IPHTTPS interface didn’t show any errors…
netsh advf monitor show mmsa
netsh advf monitor show qmsa
Ahah! No SAs match the specified criteria. So no security associations were being made. But… Why?!
After some googling I stumbled upon some threads where they asked is the IKE and AuthIP IPsec Keying Modules service running?
And indeed, on my faulty client this service was stopped and had a startup type of manual. Starting the service just once seemed to immediately reconfigure the startup type to automatic as well. And in a matter of seconds the DA connectivity seemed fine. Security Associations were now successfully created:
In the days after more and more newly assigned clients seemed to suffer this phenomena. So, as a workaround, I configured the IKE and AuthIP IPsec Keying Modules service with an automatic startup type using GPO:
And the actual setting:
If anyone has a an explanation as to why this suddenly stopped working I’d be happy to hear it. Perhaps some patch was released who “broke” the DA/IPSec stuff to get the service running?