I would keep the situation between on-premises and cloud/Azure the same. So, either reduce MTU for both to avoid fragmentation, or move to RadSec for both. And for a deployment where UDP may be problematic, like with Azure, I would check if RadSec is a viable option to avoid UDP/fragmentation. I've seen many cases where a switch resolved a lot of issues.
For the failover, as well... keep things as much the same between on-premises and in the cloud, similar to a full on-premises cluster. Keep the same certificates on all nodes, and if these are in the sale ClearPass cluster, services and trust list is all synchronized. If different deployments, make sure those are the same.
For failover, there are multiple possibilities, but using a backup radius (RadSec) server in your switch/ap/controller configuration is one common option. Using anycast/network load balancers, such that the service is always available is another option where you don't need to rely on the backup server feature on your network devices.
If you have urgent issues, always contact your HPE Aruba Networking partner, distributor, or Aruba TAC Support. Check
for how to contact HPE Aruba Networking TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or HPE Aruba Networking.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
Original Message:
Sent: Aug 18, 2025 08:05 AM
From: Cleiton da Silva dos Santos
Subject: EAP-TLS Wired Timeout 9002 - Deleting request sessid - Windows 11 802.1x Failed Reason 0x70004
In a scenario where we have ClearPass on-premises as the primary and ClearPass in the cloud (Azure) as a backup/failover:
If EAP-TLS authentication already works normally on-premises, will any specific adjustments (e.g., RadSec, MTU, etc.) also be necessary for ClearPass in the cloud to ensure continuity?
Are there any limitations or recommendations from Aruba for hybrid environments (on-premises + cloud) regarding certificate consistency, trust lists, and service replication?
In the event of a failover to the cloud, can the controllers (or Aruba Central) seamlessly switch, or would it be necessary to manually adjust the communication methods (RADIUS/RadSec)?
Original Message:
Sent: Aug 18, 2025 04:16 AM
From: Herman Robers
Subject: EAP-TLS Wired Timeout 9002 - Deleting request sessid - Windows 11 802.1x Failed Reason 0x70004
Cloud environments, at least Azure, don't like fragmented traffic. In many cases it's dropped somewhere in the Azure network security system.
Best solution is a move to RadSec, if you can, as RadSec uses TCP and doesn't suffer the fragmentation problem as it's handled at the TCP level. Otherwise, make sure there is no EAP fragmentation. There are other reasons for timeouts, like a not reachable/not responding authorization source, which results in intermittent timeouts. But there also may be dynamic/optimized routing in place that make that some authentications succeed (path MTU sufficient) and others fail on a different network path.
If you still have issues, it may be better to open a TAC case or work with your partner to get this investigated and resolved.
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your HPE Aruba Networking partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact HPE Aruba Networking TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or HPE Aruba Networking.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
Original Message:
Sent: Aug 16, 2025 07:16 AM
From: Cleiton da Silva dos Santos
Subject: EAP-TLS Wired Timeout 9002 - Deleting request sessid - Windows 11 802.1x Failed Reason 0x70004
Good morning, everyone.
I'm facing a similar situation and would like to know if anyone has experienced this and found a solution.
In my case, we're migrating ClearPass from an on-premises environment to the cloud (Azure), using the on-premises environment backup. During the approval phase, we're experiencing several authentication timeouts; at times, authentication via EAP-TLS (Wi-Fi) works normally, but then the timeouts recur intermittently.
Has anyone experienced a similar situation or have any recommendations or directions for investigation?
Environment details:
ClearPass version 6.11.11
Authentication method: EAP-TLS (Wi-Fi)
Migration using the on-premises environment backup
I appreciate any help or suggestions.
Original Message:
Sent: Aug 06, 2025 01:36 PM
From: Jordan VIVET
Subject: EAP-TLS Wired Timeout 9002 - Deleting request sessid - Windows 11 802.1x Failed Reason 0x70004
Hello Community,
I'm facing an issue for the past few weeks with my new ClearPass and AOS-CX 802.1x.
On all my Windows supplicants (manually configured for now due to ongoing troubleshooting) using EAP-TLS with a machine certificate, I consistently get a timeout in ClearPass. I've tested with user certificat, and EAP-TEAP, and same issue.
The client trusts the Root CA that signed the RADIUS certificate on ClearPass. I'm also using the same certificate for 802.1X Wi-Fi authentication with EAP-TLS, using the same ClearPass server and RADIUS certificate, and it works fine, no issues in ClearPass for Wi-Fi authentication.
In the Access Tracker, I can see that EAP-TLS is correctly detected under Computed Attributes, but there is no information about the certificate or the issuing CA.
I suspect the Windows supplicant is not sending the certificate...
Please find below the error shown in Access Tracker:
2025-08-05 09:55:12,521 [Th 37 Req 60473 SessId R000018f6-02-68920d40] INFO RadiusServer.Radius - reqst_update_state: Access-Challenge 25:1074:F8-B4-6A-93-83-74:AKsAaADKAGI57AAAiOP2B6u+2YaKlG4OlYHHwg==2025-08-05 09:56:11,546 [main SessId R000018f6-02-68920d40] ERROR RadiusServer.Radius - reqst_clean_list: Deleting request sessid - R000018f6-02-68920d40, state - AKsAaADKAGI57AAAiOP2B6u+2YaKlG4OlYHHwg=2025-08-05 09:56:11,546 [main SessId R000018f6-02-68920d40] ERROR RadiusServer.Radius - reqst_clean_list: Packet 19:188:88:F8-B4-6A-93-83-74 recv 1754402112.462707 - resp 1754402112.4720802025-08-05 09:56:11,546 [main SessId R000018f6-02-68920d40] ERROR RadiusServer.Radius - reqst_clean_list: Packet 20:201:88:F8-B4-6A-93-83-74 recv 1754402112.478091 - resp 1754402112.4791192025-08-05 09:56:11,546 [main SessId R000018f6-02-68920d40] ERROR RadiusServer.Radius - reqst_clean_list: Packet 21:634:1124:F8-B4-6A-93-83-74 recv 1754402112.493202 - resp 1754402112.4964992025-08-05 09:56:11,546 [main SessId R000018f6-02-68920d40] ERROR RadiusServer.Radius - reqst_clean_list: Packet 22:201:1120:F8-B4-6A-93-83-74 recv 1754402112.501809 - resp 1754402112.5027812025-08-05 09:56:11,546 [main SessId R000018f6-02-68920d40] ERROR RadiusServer.Radius - reqst_clean_list: Packet 23:201:1120:F8-B4-6A-93-83-74 recv 1754402112.507823 - resp 1754402112.5088522025-08-05 09:56:11,546 [main SessId R000018f6-02-68920d40] ERROR RadiusServer.Radius - reqst_clean_list: Packet 24:201:1120:F8-B4-6A-93-83-74 recv 1754402112.513877 - resp 1754402112.5148912025-08-05 09:56:11,546 [main SessId R000018f6-02-68920d40] ERROR RadiusServer.Radius - reqst_clean_list: Packet 25:201:1074:F8-B4-6A-93-83-74 recv 1754402112.520224 - resp 1754402112.521132
With TAC, we captured packets from ClearPass and observed that ClearPass is sending the certificate challenge but not receiving any reply from the client.
From the NAD (AOS-CX), I've updated to the latest firmware (10.13.x) and reviewed the configuration, and changed differents settings but same issue:
interface no shutdown no routing vlan access x qos trust dscp rate-limit broadcast 1000 pps spanning-tree bpdu-guard spanning-tree tcn-guard port-access fallback-role xxx port-access onboarding-method concurrent enable aaa authentication port-access allow-cdp-bpdu aaa authentication port-access allow-lldp-bpdu aaa authentication port-access client-limit 5 aaa authentication port-access critical-role xxx aaa authentication port-access reject-role xxx port-access allow-flood-traffic enable aaa authentication port-access dot1x authenticator eapol-timeout 3 max-eapol-requests 2 max-retries 1 reauth enable aaa authentication port-access mac-auth reauth enable client track ip enable loop-protect exit
On the Windows 11 client, I updated the Intel i219-V driver to the latest version, reinstalled Windows, and rejoined the device to the Active Directory, but it's not enrolled in our MDM (Intune). The issue persists.
I also checked the applied GPOs using gpresult to ensure there are no conflicting settings, everything looks fine.
I verified the network card driver settings as well.
In the Event Viewer on the client (supplicant), I see an error at the exact time of the timeout in ClearPass (sorry, it's in French):
Reason: 0x70004
Reason Text: The network stopped answering authentication requests
So the issue likely comes from the supplicant, but I don't know what else to check. I've reviewed many settings without finding a solution.
Thank you Team.
------------------------------
Best regards.
Jordan V.
------------------------------