Direct Access 2012 and Windows 7 Workstation Failed IPsec Authentification RRS feed

  • Question

  • Hello everybody,

    I'm currently having trouble with IPSEC authentification of Windows 7 nomade client with Direct Access on Server 2012.

    Direct Access is enabled for Windows 7 and Windows 8. Problem impact ONLY Windows 7. Client with Windows 8 working Well.

    I connect to DA serveur with IP-HTTPS, i have my own Internal PKI (Windows Sevrer 2003). i auto-enroll computer certificat with GPO.  template is "Computer" Cetificat (client authentification, server Authentification).

    if i enroll computer certificats to a windows 7 client, and connect it to internet, it connect with Direct Access without problem. i can see Quick Mode/Principal Mode, working for IPSec tunnel.

    BUT, if i shut down this computer, waitng 12h-15hours, and connect it to the internet again, i can't get connected to DirectAccess anymore, indeed IPSec authentification failed.

    Windows 8 computer ARE NOT impacted. (they use proxy kerberos i guess).

    To get the Windows 7 nomade computer working again i need to connect it to the Enterprise network, and do an "GPUPDATE /force" (with Auto-enroll certificats GPO enbaled) , deconnect, reconnect to the internet, and working again with Direct Access! weird!

    looks problem comming with time (ntp) and Certificats.? my certificats is not expired since all are valid for 1 years!

    best Regards,


    • Edited by Marc Berger Tuesday, November 6, 2012 2:59 PM
    Tuesday, November 6, 2012 2:47 PM

All replies

  • Hi,

    It sounds like your using an internal certificate and not publishing the CRL to the internet and so that's why you have to connect the client to the domain and do a gpupdate. because it is updating the CRL cache on the client.

    I would recommend using a public certificate and so the client can access the CRL anywhere.

    Regards, Rmknight

    • Edited by rm_knight Tuesday, November 6, 2012 10:20 PM typo
    Tuesday, November 6, 2012 10:19 PM
  • Hello rm_knight,

    that's what I thought too, BUT since i use IP-HTTPS with internal Certificats (type web server), my CRL is published to internet, so my windows 7 clients can connect to my CRL from internet. By the way, IP-HTTPS working well (since Windows 8 client are OK). problem come from Computer certificats for IPSec auth.

    Thx for your help,


    • Edited by Marc Berger Tuesday, November 6, 2012 11:17 PM
    Tuesday, November 6, 2012 11:16 PM
  • Hi Marc,

    It sounds like it only works for as long as you have a cached copy of the CRL, so you need to connect back to corpnet to update the CRL cache. IP-HTTPS will not work unless the client can fully validate revocation information.

    Are you sure the CRL is accessible externally and working correctly?

    The best way to test this is to export a copy of your IP-HTTPS certificate into CER format (e.g. without the private key) and then run the following command from the externally connected client:

    certutil -urlfetch -verify C:\[IP-HTTPS Exported Certificate Filename].cer

    More info:



    Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: and

    Thursday, November 8, 2012 12:35 AM
  • Hi Jason,

    Ok, weird, because my  CRL is available from internet. i will have more check of this, and try with a Certificats from GlobalSign, or another Public Certificats to see if it works better.

    So since Windows 8 working well with IP-HTTPS, it doesnt need CRL check ? only Windows 7 need it ? you OK with that?

    Another thing, in a Windows 7 Clients that can't connect DA from internet, if i do a "NETSH.EXE INTERFACE HTTPSTUNNEL SHOW INTERFACES" , i can see "IP-HTTPS connection Active" error

    another test i did : "CERTUTIL -url http://url-of-my-crl"

    and i can get it.

    What do you think about that ?

    Best Regards,

    Thursday, November 8, 2012 11:02 AM
  • Don't forget, the IPsec tunnels run within the SSL tunnel, so you are having a problem with the IPsec certificate authentication, not the IP-HTTPS "wrapper".

    By default, the IPsec certificates shouldn't be CRL checked, but that does kinda sound like what is happening.

    Have a check through the guidance here: and pay particular attention to the IPsec auditing information.



    Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: and

    Friday, November 9, 2012 11:17 AM
  • Hi,

    Well, did some tests, looks Windows 7 clients don't check correctly the CRL. My CRL is available on internet for shure, this is tested.

    I tried with a Public Certificat too (GlobalSign approuved by Windows in the Trusted Root Certification Authorities"), so a public CRL, i can't connect with IP-HTTPS, due an CRL error.

    So Windows 7 Clients dont go to the CRL Check... that weird..

    any idea about what can cause this ?



    Friday, November 16, 2012 4:16 PM
  • Hi Marc,

    I was having the same problems with Windows 7 and Windows 8 clients. But I think i have solved the problem for our organisation. I have a single Windows 2012 server running Direct Access, i createted a Multisite so that Windows 8 and Windows 7 have there own policy and AD security groups. My CRL check is not working so i still have problems with Windows 8 client but Windows 7 are running stable now and i have not experienced any problems for a week now.



    Monday, December 3, 2012 6:51 AM
  • Marc,

    We are experiencing the exact same issue in our environment. We are using the internal PKI, Clients Auto Enroll and we have a significant Windows 7 presents in our DA clients. Our Windows 7 Clients fail at some point or another usually you can expedite the problem by hibernating the system. Windows 8 systems do not experience the issue. our CRL is publicly available.

    The current work around is to VPN in and do a GPUPDATE /force, disconnect VPN and then DA reestablishes itself.

    I saw the last post here that said doing a Multi-site deployment corrected there issues and we are going to do Multi-site however we would like to get our single site stable before introducing more complexities that a multi-site would bring...

    Did anyone come up with a solution to this?

    Tuesday, September 3, 2013 6:09 PM
  • Hi,

    I was the one that wrote about doing the Multi-site solution. I experienced the same problems as you before I done this deployment. It looks like mixing Windows 7 en Windows 8 is not working well. By useing the Multi-site option I have 2 DirectAccess client policies, one for Windows 7 and one for Windows 8. I build this Multi-site on one DirectAccess server and it's working perfect for almost a year now.



    Thursday, September 5, 2013 5:05 AM
  • Hello jcstacy,

    Well,i got solutions for this troubles. Indeed, when checking CRL, Windows use SYSTEM account, and not the current AD user account logged on the OS.. So, make SHURE there is any proxy (i mean internal enterprsise proxy) specified on Internet Explorer, on the SYSTEM account. (curiously, when proxy is specified for user, it specified for SYSTEM account too..weird..)

    To check that, you need to run IE with system account, with psexec (sysinternal tools). command line is like : "psexec -i -s iexplorer.exe" , and check Proxy Settings on IE and disabled it !

    Proxy setting for system account, disabled internet connectivity for checking CRL on internet for DA Certificats.

    That perfectly work for me, and i get in touch with other customers that got this weird trouble!

    Hope this help,



    • Edited by Marc Berger Tuesday, September 10, 2013 10:48 PM wrong word
    Tuesday, September 10, 2013 10:47 PM