Hello, I have a Clearpass server version 18.104.22.168650. During the implementation of the solution, we encountered issues with client timeouts.
On some Windows 10 computers, random timeouts occur, usually during reauthentication (sometimes after the computer power on).
Has anyone dealt with a similar problem?
The issue appears randomly; one week a particular computer may authenticate without any problems, while in the following week, it may experience timeouts.
It looks like this:
When observing the PCAP from the workstation, it seems like the Windows 802.1x supplicant stops responding at a certain point in time.
I have tested various Windows 10 versions and builds, including 21H2 and 22H2, different GPO settings for PEAP MSCHAPv2 or TEAP TLS + MSCHAPv2, with and without server certificate validation.
The network card drivers are up to date, and I have disabled energy-saving features for the network card as well as sleep/hibernation modes in Windows.
Additionally, Credential Guard is disabled. We use different switches like HPE Comware 5 and 7, Aruba 6200, but unfortunately, the problem persists.
Any guidance or suggestions would be greatly appreciated.
Does this actually cause any user impacts? Timeouts are normal for things like initial boot up, wake from sleep, etc.
When it comes to booting up the computer, sometimes there is an immediate timeout issue that can be resolved by restarting, unplugging and re-plugging the network cable, or toggling the port on the switch.
Unfortunately, timeouts also occur during reauthentication, which is problematic for users as it disconnects them from the network while they are working. Timeouts are random; on one station, it may be fine for up to 5 days, then experience a timeout, while at other times, there are several timeouts in a day.
I see recently this issue (timeout on re-authentication with EAP-PEAP-MSCHAPv2 for Windows 10/11 devices) coming up more frequently. This (coincidently?) matches up with updates in Windows and Credential Guard. The strong recommendation (Microsoft) is to move to EAP-TLS, for which I have not seen the same issue.
Would it be possible for you to open a TAC support case, to get this further investigated?
Capturing the RADIUS/EAP traffic from ClearPass and on the client would probably help to analyze what's happening, but I would guess this is a client behavior change issue, not ClearPass. Reducing the reauthentication timer (sending IETF:Session-Timeout with like 300 (seconds = 5 minutes) for your test client) may help to trigger the issue.
We recently conducted a test with EAP-PEAP, EAP-TLS for one computer; however, timeouts during reauthentication are still occurring. The issue was investigated with Aruba support, but according to their assessment, ClearPass is not the culprit here.
Looking at the captured traffic during reauthentication, I am inclined to believe that the issue lies on the client side. It's as if, for some reason, the supplicant is experiencing delays in receiving responses.
We recently became aware of an issue with AOD 22.214.171.124 with AP models 5XX & 6XX. We currently have a TAC Case open.
Radio reset under "Total Radio Resets" in the "show ap debug radio-stats ap-name <apname> radio 0/1 advanced" output is known to show some counters in general. Radio reset takes around 10-20ms to finish which doesn't affect clients association. But only resets the radio hardware queue and some registers.The issue seen at Iowa is because of "phy_warm_reset_reason_tx_hwsch_reset_war" which is a type of hardware radio reset that was increasing exponentially(100K+) within seconds preventing APs from transmitting anything out to the client. This impacts 126.96.36.199, 188.8.131.52, and 184.108.40.206 And the AP models impacted are 5XX and 6XX (Example 530s, 550s, 630s, 650s). The following command could be used to validate,
Interesting. I will be curious to see what the outcome of that is.
Last rumor I heard was 220.127.116.11 was the target for the fix.
© Copyright 2023 Hewlett Packard Enterprise Development LPAll Rights Reserved.