- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2023 10:34 AM
I have a scenario where we use ISE for EAP-TLS cert based authentication for wireless network. It has been working at our HQ for several months. Now we are trying to roll this out to our remote offices that connect to HQ over private WAN links.
The issue we are seeing is that when we try the authentication process in the remote sites, the WAP are sending the authentication information to ISE but the logs are showing it coming in as Authentication method : login.
We have a test WAN link that we used to verify our WAP configurations and it works great, the Authentication method is listed as: 802.1x and it works as it should.
I verified the WAP settings are the same, I cannot figure out why the Auth requests are coming in as Login type instead of 802.1x. This is causing the authentication policy in ISE to skip the 802.1x wireless/cert identity store process and fall to the default which is deny access.
Here are the main differences from the WAN test link and remote branch office.
The remote branch that is failing is using an older 4507 L3 switch which is what the WAP connects to, while the test WAN site is using C1000 switch for the WLC to connect ....The other variable is that the remote branch is using an ASA to serve the DHCP address to the wireless clients while that is being handled by the WAN router on the test link. I am really at a loss on this one and hoping for any ideas or insights.
Solved! Go to Solution.
- Labels:
-
ISE
-
Wireless Security
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2023 01:04 PM
I am pretty sure its this:
https://bst.cisco.com/bugsearch/bug/CSCuf16911
I am waiting to do some testing to confirm. I noticed the successful WAP has that command on it, the one failing does not.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2023 11:09 AM
Hi
Do you have WLC or this is autonomous Access Point?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2023 11:29 AM
Autonomous. I pulled a packet capture from the WAN test site (working) vs the remote branch (failed) and I verified AVP attribute 6 is coming in as type "Login" on failed site vs "framed" on working site. I also realized the failing branch location is a MOE WAN link while the test WAN setup in an MPLS circuit....is that part of the issue?
The last thing I noticed in the packet captures is the MOE AVP (79) EAP message is fragmented, its entire length is listed as 1492 while the MPLS capture has AVP (79) as length=35 and not fragmented.
Does the type of WAN circuit effect the EAP ability?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2023 11:46 AM
For EAP-TLS which seems to be your case, MTU can be a problem but on this case it would prevent clients from authenticate.
But in your case, seems to be a configuration problem. Did you compared the configuration from one working AP to the non-working one ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2023 11:52 AM
Yes, 2 of us went over it in detail, the WAP are configured the same. I am focused on the WAN links causing the issue, I don't know enough about the difference from MOE to MPLS but EAP-TLS but I feel that seems to be the culprit....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2023 12:15 PM - edited 05-11-2023 12:15 PM
If the AP have the exactly same config, then, it could be the link. I got into a problem related to the MTU in the past but, in that case, the behavior was a bit different. But, it was WLC and not WAP.
The problem was fragmentation on the Load Balancer and we had a IPS in between.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2023 12:26 PM
OK thanks, still digging.
I found in the packet capture the failed attempt is showing VSA (vendor specific attribute) is sending t=WISPr-location-name val=(site name) while the successful one is sending t=Cisco-AVPair val=service-type-framed.
trying to find the reason why.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2023 12:53 PM
I saw this information and that's why I think that the config is not ok, but as you said they are the same on both sides. I would correlated this parameter change to a link.
I will waiting on your new findings
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2023 01:04 PM
I am pretty sure its this:
https://bst.cisco.com/bugsearch/bug/CSCuf16911
I am waiting to do some testing to confirm. I noticed the successful WAP has that command on it, the one failing does not.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2023 01:15 PM
Sounds promissor. But then you have differents AP versions? Otherwise this would affect your whole network
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2023 01:34 PM
That was the problem, one of those famous "undocumented features". The reason it doesn't affect the entire network is because we are using WLC in our main HQ LAN. We are only using autonomous WAP in our branch locations. The command was already on the WAP we had on the WAN test lab, it must have been a newer WAP that was shipped with the command.
We did compare the radios though GUI but this is an undocumented command as a workaround to the bug i listed so we had to enable it on the WAP that is at the branch location.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-14-2023 03:19 PM
For anyone reading this thread later the command is:
dot11 aaa authentication attributes service framed
So lesson learned - don't glance at a GUI and say "they're configured the same"! Always look at the actual config and compare them side by side, or use any of the numerous file compare tools to diff the configs. Apart from expected differences like IP addresses and descriptions you'd expect the configs to be more or less identical and you'll quickly spot any difference that way.
Just to add - while WAN links can make a difference to radius because it's UDP and MTU can come into play - a WAN link would never change the contents of a radius packet so if different parameters are being sent that must always be from the source of the packet.
Please click Helpful if this post helped you and Select as Solution (drop down menu at top right of this reply) if this answered your query.
------------------------------
TAC recommended codes for AireOS WLC's and TAC recommended codes for 9800 WLC's
Best Practices for AireOS WLC's, Best Practices for 9800 WLC's and Cisco Wireless compatibility matrix
Check your 9800 WLC config with Wireless Config Analyzer using "show tech wireless" output or "config paging disable" then "show run-config" output on AireOS and use Wireless Debug Analyzer to analyze your WLC client debugs
Field Notice: FN63942 APs and WLCs Fail to Create CAPWAP Connections Due to Certificate Expiration
Field Notice: FN72424 Later Versions of WiFi 6 APs Fail to Join WLC - Software Upgrade Required
Field Notice: FN72524 IOS APs stuck in downloading state after 4 Dec 2022 due to Certificate Expired
- Fixed in 8.10.196.0, latest 9800 releases, 8.5.182.12 (8.5.182.13 for 3504) and 8.5.182.109 (IRCM, 8.5.182.111 for 3504)
Field Notice: FN70479 AP Fails to Join or Joins with 1 Radio due to Country Mismatch, RMA needed
How to avoid boot loop due to corrupted image on Wave 2 and Catalyst 11ax Access Points (CSCvx32806)
Field Notice: FN74035 - Wave2 APs DFS May Not Detect Radar After Channel Availability Check Time
Leo's list of bugs affecting 2800/3800/4800/1560 APs
Default AP console baud rate from 17.12.x is 115200 - introduced by CSCwe88390
