11-28-2023 06:02 AM - edited 11-28-2023 06:02 AM
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.
11-28-2023 06:27 AM
- 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.
11-28-2023 07:33 AM
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
11-28-2023 08:19 AM
- Check full radius logs on ISE too (if not yet done) ,
M.
11-28-2023 11:54 PM - edited 11-29-2023 12:35 AM
- 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.
11-29-2023 07:00 AM
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
11-29-2023 07:51 AM
- Looks like traffic blocking by some device ; is there a free path between the WLC and ISE ?
M;
11-29-2023 07:56 AM
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?
11-29-2023 08:25 AM
> .. 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.
11-29-2023 06:06 PM
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.
11-30-2023 06:29 AM
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?
11-30-2023 06:52 AM
- Possibly : https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwi25328
M.
11-30-2023 03:20 PM
Weird and makes no sense. Open a TAC case and let them work it out for you.
11-30-2023 07:46 AM
Hi friend
What cert you use for peap in client?
MHM
12-04-2023 01:23 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide