9800L ISE dot1x PEAP timeout

[martin0009]

Hello community,

I have a problem with 802.1x PEAP authentication.

The environment is WLC 17.9.4  and ISE 2.4.
APs are in local switching.

When user tries to connect, I see request on ISE and then authentication times out.
ISE says  "5440 Endpoint abandoned EAP session and started new"

The client says "Reason: There was no response to the EAP Response Identity packet."

On the client, using Microsoft network monitor I see EAPOL, EAP req / response
The client has a manual configuration of wireless network, configured to use WAP enterprise, PEAP/MSCHAPv2.

I went and captured traffic on the WLC, I see EAP req / response, and then RADIUS access-challenge.
The Radius packet says "Type:protected eap eap-peap"
The WLC should now create EAPOL EAP-req  and send it to the client.
This never happens and both ISE and client complain about auth timeout.
I have changed auth timeout timers, but it only takes longer for connection to fail..

Maybe it's something obvious, misconfiguration or something, but I don't see it.

[marce1000]

 - Client debugging according to https://logadvisor.cisco.com/logadvisor/wireless/9800/9800ClientConnectivity may provide extra insights ; you can have client debugs (RadioActive Traces) analyzed with : https://cway.cisco.com/tools/WirelessDebugAnalyzer/

 M.

[martin0009]

I already did it, but don't see anything useful, except one message: 
Client made a new Association to an AP/BSSID:
Also in the debug I see that WLC is sending radius to ISE, but at the same time there is no traffic in .pcap...

here is the whole output, interesting part is that after the radius message 

[marce1000]

             - Check full radius logs on ISE too (if not yet done) , 

 M.

[marce1000]

 - Added reply ; probably not related to this issue (because 'radius is radius') ; but your ISE version is way End of Life/End of Support 
                 for business continuity  consider upgrading and or using modern and supported ISE version , 
                                                                                     That being important too when a TAC case must be created

 M.

[martin0009]

I found out that WLC does not send radius to ISE due to the network error:

what could be reason for this?

Once client stops trying, WLC will send messages to ISE and get response, but by that time, the initial session will already expire

2023/11/29 15:34:18.448440397 {wncd_x_R0-0}{2}: [radius] [23598]: (info): RADIUS: wlan-group-mgmt-cipher[189] 6 " "
2023/11/29 15:34:18.448451007 {wncd_x_R0-0}{2}: [radius] [23598]: (ERR): IPv4 SendMessage failed with error Network is unreachable
2023/11/29 15:34:18.448451699 {wncd_x_R0-0}{2}: [radius] [23598]: (ERR): Error in sending out of the socket Network is unreachable
2023/11/29 15:34:18.448452083 {wncd_x_R0-0}{2}: [radius] [23598]: (ERR): RADIUS(00000000): Sending a IPv4 Radius Packet failed
2023/11/29 15:34:18.448466495 {wncd_x_R0-0}{2}: [radius] [23598]: (info): RADIUS: Started 64 sec timeout
2023/11/29 15:34:18.448762313 {wncd_x_R0-0}{2}: [radius] [23598]: (ERR): Invalid parameter in BSOCK response

[marce1000]

  - Looks like traffic blocking by some device ; is there a free path between the WLC and ISE ?

 M;

[martin0009]

sorry but are you a bot?

If something was blocking the traffic, wouldn't is see the traffic going out of the interface? and there would not be return traffic?

I don't see traffic going out of WLC, how does the WLC knows that the network is unreachable?

[marce1000]

                               > .. how does the WLC knows that the network is unreachable?
   That's a bit like biting on the problem  ; it just uses standard network protocols ; you could for instance use a tool like https://www.iea-software.com/products/radiusnt/radlogin4.cfm and test from a host on the same subnet as the WLC

 M.

 M.

[Rich R]

9800 is IOS-XE - the radius needs to be reachable via routing table and radius needs to be able to reply back to the WLC.

So start with "sh ip route" to make sure you have a valid route to reach the radius IP.  Make sure you're sending the radius from the correct source IP address - by default it will simply use the outbound interface IP (based on the outbound interface selected according to the routing table).  Maybe try pinging the radius from the same source interface for a start to prove network connectivity.

When doing packet captures it often also helps to include control-plane in case the packets aren't going out the interface you thought they were.  That will also show you source and destination IP regardless of outgoing interface.

[martin0009]

I found a problem, but don't know the reason or the cause.
check the picture bellow. 
Routing is not a problem, WLC can reach ISE all the time.
Problem is that WLC waits after receiving "eap identify response" to send RADIUS access request ti ISE.
And it receives instant reply. 
But in this pcap 5 minutes passed since initial eap identity message.

Whole time WLC is reachable from LAN and responding to pings. There is no routing, as per best practice. There is only one L3 interface on the WLC.

Any ideas what could delay the traffic?

[marce1000]

       - Possibly  : https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwi25328

 M.

[Rich R]

Weird and makes no sense.  Open a TAC case and let them work it out for you.

[MHM Cisco World]

Hi friend 

What cert you use for peap in client?

MHM

[martin0009]

a client only needs to verify server cert. 
but this is not important because we never reach this step.
I don't want to post picture of EAP process here,  the process is failing on the "radius access request" from WLC, and then repose from ISE to WLC.