cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10428
Views
10
Helpful
4
Replies

Some Win 10 clients get "12935 Supplicant stopped responding to ISE during EAP-TLS certificate exchange" errors

rmoat
Level 1
Level 1

Hello,

I'm working with our networking team to get 802.1x EAP-TLS authentication working. It has been successful so far with many of the machines that we've been testing. However, I received a message stating that one of the networking laptops was trying to authenticate and in Cisco's ISE logs it was showing this error: "12935 Supplicant stopped responding to ISE during EAP-TLS certificate exchange".

I've checked all the 802.1x settings, and I have also deleted the computer certificate, and let our Group Policy autoenroll the computer with another certificate to see if that was the issue. I'm still getting the same error on this specific Windows 10 machine, and I'm not sure what else would be different compared to the other clients. When we enroll the entire company into 802.1x, I'd like to say that everything will just work, but I would most likely be wrong.

Is there any further troubleshooting I can do, or things I can check? I noticed my laptop is on Windows 10 1909, but the Windows 10 that was failing was on Windows 10 1807. The version shouldn't matter, but right now I'm not quite sure what I can do with this machine.

1 Accepted Solution

Accepted Solutions

In addition to the suggestions provided by @Damien Miller, I have also seen some client software (like an old Citrix VPN client) use a packet driver that intercepted the EAPOL frame from the switch and did not pass it to the supplicant.

If you have Win10 PCs that do work, in addition to checking driver versions, you should check for any difference in the installed applications, patches, etc. compared to the non-working PC.

Typically, these issues require taking packet captures on the switch, client PC, and potentially ISE to compare what's happening with the EAP and RADIUS handshakes. You might need to engage TAC to assist in troubleshooting at that level.

 

Cheers,

Greg

View solution in original post

4 Replies 4

Damien Miller
VIP Alumni
VIP Alumni
Versions are very important, whether it is the version of windows, or the version of the drivers on the NIC. Versions don't just get released for new features, but to fix bugs. Are you hitting a bug here? impossible to say right now.

It's a long list, here are some of the most common issues.
Are you using the same certificate for EAP on all your ISE nodes? Are they CA signed certs for EAP? Does the client machine having the issue have the trust chain installed in their certificate store? Does ISE have the trust chain installed for the client's enrolled certs? Does the supplicant configuration have any differences? On the supplicant configuration, are there any server names specified to trust?

In addition to the suggestions provided by @Damien Miller, I have also seen some client software (like an old Citrix VPN client) use a packet driver that intercepted the EAPOL frame from the switch and did not pass it to the supplicant.

If you have Win10 PCs that do work, in addition to checking driver versions, you should check for any difference in the installed applications, patches, etc. compared to the non-working PC.

Typically, these issues require taking packet captures on the switch, client PC, and potentially ISE to compare what's happening with the EAP and RADIUS handshakes. You might need to engage TAC to assist in troubleshooting at that level.

 

Cheers,

Greg

Thank you, Greg! I did not see your response until today; however, this is very helpful to know. Very much appreciated!

Hello,

 

Thanks for the details.

 

I'm facing the same issue in my environment.

We have been using ISE and 802.1x EAP-TLS on windows 7 laptops for 2 years and it worked fine.

Now we are moving to Win 10 (1909), and some get "12935 Supplicant stopped responding to ISE during EAP-TLS certificate exchange".

 

What is anoying is the fact is it intermittent.

Our technicians deploy a laptop, perform a few tests and reboot it: all fine.

A couple of hours later, or the next day, we have 2% of the laptop with no connection.

We have 800+ computers on the site.

The authentication keeps trying, and sometime the end user get authenticated again without any change.

In case of emergency for a specific user, the technicians change authentication to MAB, and the problem is solved.

 

Greg, I saw the other thread about the same issue, where you recommand to check mtu.

We have "system mtu 9000" on our 9300 switchs (IOS 16.9.3).

I'm trying to revert it back to 1500 but is required by some applications on some of our switches, so I have to be careful.

 

What I'm trying to understand is where is the issue : is it between the supplicant and the switch ? (then it could be related to the laptop network drivers, OS version, cabling....) or is it between the switch and ISE server ?

In our environment ISE is in a datacenter, and we have MPLS lines between the buildind and the ISE server.

So if the issue is between the switch and ISE, I shall focus my troubleshooting on MTU mismatchs, packet loss on the WAN and QoS

Also, in order to allow fragmentation, I've been checking and confirm our firewall don't filter ICMP Packet too big packets.

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: