02-18-2020 06:50 AM - edited 02-21-2020 11:13 AM
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.
Solved! Go to Solution.
02-20-2020 02:02 PM
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
02-19-2020 11:44 PM
02-20-2020 02:02 PM
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
03-09-2020 08:36 AM
11-05-2020 01:02 AM
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.
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: