Dot1x failing on devices configured for Always on

[awinslade]

I Have an issue where 'normal' domain devices  are  authenticating correctly to ISE however Windows devices that have also been configured for always on fail to correctly authenticate  

From the logs below you can see that it get very close but fails at the last hurdle with the device failing and ISE reports  "Supplicant stopped responding to ISE after sending it the first inner EAP-MSCHAPv2 message"

I suspect a windows config tweak needed 

thoughts?

11001	Received RADIUS Access-Request
	11017	RADIUS created a new session
	15049	Evaluating Policy Group
	15008	Evaluating Service Selection Policy
	11507	Extracted EAP-Response/Identity
	12500	Prepared EAP-Request proposing EAP-TLS with challenge
	12625	Valid EAP-Key-Name attribute received
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12301	Extracted EAP-Response/NAK requesting to use PEAP instead
	12300	Prepared EAP-Request proposing PEAP with challenge
	12625	Valid EAP-Key-Name attribute received
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12302	Extracted EAP-Response containing PEAP challenge-response and accepting PEAP as negotiated
	12318	Successfully negotiated PEAP version 0
	12800	Extracted first TLS record; TLS handshake started
	12805	Extracted TLS ClientHello message
	12806	Prepared TLS ServerHello message
	12807	Prepared TLS Certificate message
	12808	Prepared TLS ServerKeyExchange message
	12810	Prepared TLS ServerDone message
	12811	Extracted TLS Certificate message containing client certificate
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	12318	Successfully negotiated PEAP version 0
	12812	Extracted TLS ClientKeyExchange message
	12813	Extracted TLS CertificateVerify message
	12804	Extracted TLS Finished message
	12801	Prepared TLS ChangeCipherSpec message
	12802	Prepared TLS Finished message
	12816	TLS handshake succeeded
	12310	PEAP full handshake finished successfully
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	12313	PEAP inner method started
	11521	Prepared EAP-Request/Identity for inner EAP method
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	11001	Received RADIUS Access-Request
	11018	RADIUS is re-using an existing session
	12304	Extracted EAP-Response containing PEAP challenge-response
	11522	Extracted EAP-Response/Identity for inner EAP method
	11806	Prepared EAP-Request for inner method proposing EAP-MSCHAP with challenge
	12305	Prepared EAP-Request with another PEAP challenge
	11006	Returned RADIUS Access-Challenge
	12937	Supplicant stopped responding to ISE after sending it the first inner EAP-MSCHAPv2 message ( Step latency=120000 ms)

[Mike.Cifelli]

So a couple of things to consider:

-Always-On can be tricky if not setup right.  On one of the troubled clients can you navigate here: C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Profile and open the VPN profile and determine what the <ConnectFailurePolicy> is set to? I dont think yours are set to close based on the clients actually being able to begin negotiations, but something to be aware of in regard to Always On (from Cisco docs): Captive portal remediation must be explicitly allowed in an AnyConnect VPN Client profile if AnyConnect Always-on is enabled and the Connect failure policy is set to Closed. If Always-on is enabled and the Connect Failure policy is set to Open, you do not need to explicitly allow captive portal remediation in an AnyConnect VPN Client profile because the user is not restricted from network access.  

-Are there any other differences between a working (non always-on) and non-working (always-on) client? I would recommend doing a comparison of supplicant configs between the two.  Read radius live logs of a working and non-working to see the differences.  Lastly, perhaps try generating a DART bundle after one of the troubled clients fails and check event viewer logs to see if that helps shed light.

[awinslade]

Thanks for your comment 

The always on solution id the built in Windows solution and not AnyConnect so we are currently researching how this operates - the working thesis is that  Windows (as the ISE log suggests) just stops responding

thoughts?

Andy