cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1069
Views
5
Helpful
2
Replies

Dot1x failing on devices configured for Always on

awinslade
Level 1
Level 1

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?

 

 

 

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

 

 Step latency=120000 ms)

 

 

 

 

 

2 Replies 2

Mike.Cifelli
VIP Alumni
VIP Alumni

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.

 

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

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: