Security

Hello, I have a Clearpass server version 6.10.8.188650. 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.

Best Regards.

Does this actually cause any user impacts?  Timeouts are normal for things like initial boot up, wake from sleep, etc.

Hello, I have a Clearpass server version 6.10.8.188650. 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.

Best Regards.

Hello, I have a Clearpass server version 6.10.8.188650. 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.

Best Regards.

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.

Hello, I have a Clearpass server version 6.10.8.188650. 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.

Best Regards.

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.

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.

Hello, I have a Clearpass server version 6.10.8.188650. 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.

Best Regards.

We recently became aware of an issue with AOD 8.10.0.7 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 8.10.0.7, 8.10.0.8, and 8.11.1.1 And the AP models impacted are 5XX and 6XX (Example 530s, 550s, 630s, 650s). The following command could be used to validate,

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.

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.

Hello, I have a Clearpass server version 6.10.8.188650. 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.

Best Regards.

Interesting.  I will be curious to see what the outcome of that is.

We recently became aware of an issue with AOD 8.10.0.7 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 8.10.0.7, 8.10.0.8, and 8.11.1.1 And the AP models impacted are 5XX and 6XX (Example 530s, 550s, 630s, 650s). The following command could be used to validate,

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.

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.

Hello, I have a Clearpass server version 6.10.8.188650. 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.

Best Regards.