Bug (?) with Corporate Connectivity is (not) Working check

Question

Noticed something odd.  In situations where:
Direct Access client is offsite
their Internet access is via WiFi
they first have to enter their access credentials through a web-based captive portal before access is granted
then the Corporate Connectivity Check process malfunctions.  Have seen cases where, after accessing the captive portal and being authenticated, Internet access works on the client.  Direct Access then connects successfully.  This is confirmed
on the server console, showing the client connected and the user credentials used.  The client is able to access internal resources just fine (e.g. network drives on file servers).
But on the client itself, it still says Corporate Connectivity is Not Working.  The WiFi icon is showing an exclamation mark.  My belief is that this is caused by the client's inability to access Microsoft NCSI servers in a timely fashion.
So it looks like the corporate connectivity checks are dependent on Microsoft NCSI checks.
Can someone at Microsoft please look into this, as it is confusing our users (not to mention us guys in IT who have only just discovered this odd behaviour!).

Answer 1

Hi Steven !
Thanks a lot for your guidance !
After I followed the steps, I found that the time out occurs when trying to resolve the internal domain name.
The Windows Firewall was enabled on all profiles ( active on the public )
There were no IPsec sessions established in the Security associations tab, so I enabled the audit policy of the IPsec as per your instructions.
There is reoccurring error in the Security log :
Date:          10/8/2014 10:08:49 AM
Event ID:      4653
Task Category: IPsec Main Mode
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      MyW8Client
Description:
An IPsec main mode negotiation failed.
Local Endpoint:
 Local Principal Name: -
 Network Address: MyW8Client_Ipv6 address
 Keying Module Port: 500
Remote Endpoint:
 Principal Name:  -
 Network Address: MY_DA_Servert Ipv6 address
 Keying Module Port: 500
Additional Information:
 Keying Module Name: AuthIP
 Authentication Method: Unknown authentication
 Role:   Initiator
 Impersonation State: Not enabled
 Main Mode Filter ID: 180987
Failure Information:
 Failure Point:  Local computer
 Failure Reason:  Negotiation timed out
 State:   Sent first (SA) payload
 Initiator Cookie:  9e636863e513b367
 Responder Cookie: 0000000000000000
As far as I understand - the connection can not be established due to certificate error, which in my case is strange since my DA configuration is set to not use computer certificates, only Kerberos.
I will keep digging but any additional tip/advice will be appreciated!
Thanks again, Steven!
P.S. Just noticed that the Event ID 4653 produce two types of "Failure Reason" - apart from "Negotiation timed out" I also get "No policy configured"