I was at a a customer recently where they were experiencing a problem with DirectAccess; roaming users, home or travelling, would suddenly lose their DirectAccess connection. Investigation revealed that these were IP-HTTPS users that were working out of office and their connections would mysteriously drop. These were normally Teredo clients but there are documented scenarios of Teredo quirks that cause a fail back to IP-HTTPS. The users in question had been travelling and logging on on other corporate LANs so fallback to IP-HTTPS was plausible (the ins and outs of Teredo behaviour can be found in the following blog entry):
On the IP-HTTPS side, we were noticing that the tunnel negotiation and setup was failing. Logs from the user(s) experiencing the problem were captured via the DirectAccess Connectivity Assistant. The details in the IP-HTTPS portion of the log were revealing:
https://access.mydomain.com:443/IPHTTPS Last Error Code : 0x80092013 Interface Status : failed to connect to the IPHTTPS server.
The Certificate Distribution Point (CDP) of the online Issuing Certification Authority could not be reached (error code 0x80092013).
The Certificate Distribution Point (CDP) offline message turned out to be misleading. The CA CDP was online and reachable, but investigation revealed a key omission in our configuration. The CDP of the Issuing CA URL was not in the Direct Access tunnel exemptions list. This meant that every X hours or so the CRL cache on the local Windows 7 clients was expiring. When the client did need to obtain a fresh CRL from the CA, it failed because of a race condition where the client was unable to setup the infrastructure tunnel because the server authentication certificate issued to the IP-HTTPS listener (running under IIS) could not be validated as the CA CDP was unreachable and the CRL not downloadable because the tunnel hadn’t been established (loop to infinity)…..
Lessons learned:
-
Use a third-party certificate to avoid the aforementioned scenario OR
-
Ensure that the URLs of certificate distribution points (CDP) are not resolved through the infrastructure tunnel and are exempt from DirectAccess
Nice!! 
Regards,
Mylo
The Access Onion 
I use internal SSL cert on my Direct Access server for IP-HTTPS. I have published my CRL URL to internet. Everything is working fine. Clients can connect & access my network. But when I am trying to check local URL cache in Clients using “certutil -URLcache crl” command, I don’t see any entry for my published crl url. But I can see the same in Direct Access server cache. Just to check what is happening, I shutdown my crl server for one and half days & these clients still can connect to network. Wondering what is exactly happening. Any Idea??
Thanks,
Hi Brajesh,
The certutil -URLcache runs in the existing session context, meaning that you’re likely only seeing the user context specifics. On the CRL timeout, there are a number of other factors at play here that determine the validity of the certificate beyond your CDP being “available” and the timeliness of the CRL. There’s a nice article here on TechNet that describes the behaviour:
http://blogs.technet.com/b/pki/archive/2006/11/30/basic-crl-checking-with-certutil.aspx
Regards,
Mylo