cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
535
Views
0
Helpful
6
Replies

Moving to the Wlc 9800 and setting up CWA with ISE

aya24
Level 1
Level 1

Hello,

We are currently moving our Guest network (CWA) from WLC 5520 to the newer WLC 9800. While configuring Central Web Authentication (CWA) with Cisco ISE, we encountered an issue where client authentication fails, and the logs indicate that the server is down.

However, when using WPA2 with 802.1X, the WLC successfully communicates with the ISE RADIUS server, and clients authenticate without any issues. The problem arises specifically when using MAC filtering, where the client should be redirected to the ISE login page but instead fails to connect.

Below is a relevant portion of our configuration:

wlan GuestVlan 21GuestVlan
ccx aironet-iesupport
channel-scan defer-priority 4
mac-filtering default
radio policy dot11 5ghz
security ft reassociation-timeout 100
no security ft adaptive
no security wpa
no security wpa wpa2
no security wpa wpa2 ciphers aes
no security wpa akm dot1x
security dot1x authentication-list ISE_Auth
no shutdown

wireless profile policy GuestVlan_policy
aaa-override
aaa-policy ISE_Policy
accounting-list ISE_Accounting
ipv4 acl ACL-REDIRECT
nac
vlan 21
no shutdown

wireless profile flex GuestWln_Flex
acl-policy ACL-REDIRECT
central-webauth
ip http client proxy 0.0.0.0 0
vlan-name VLAN021
acl ACL-REDIRECT
vlan-id 21

Blow is modified client logs:

2025/02/17 08:33:15.593281513 {wncd_x_R0-0}{1}: [client-orch-state] [19826]: (note): MAC: XXXX.XXXX.XXXX Client state transition: S_CO_INIT -> S_CO_ASSOCIATING

2025/02/17 08:33:15.593478186 {wncd_x_R0-0}{1}: [client-orch-state] [19826]: (note): MAC: XXXX.XXXX.XXXX Client state transition: S_CO_ASSOCIATING -> S_CO_MACAUTH_IN_PROGRESS

2025/02/17 08:33:15.593498128 {wncd_x_R0-0}{1}: [client-auth] [19826]: (note): MAC: XXXX.XXXX.XXXX MAB Authentication initiated. Policy VLAN 21, AAA override = 1, NAC = 1

2025/02/17 08:33:15.594785822 {wncd_x_R0-0}{1}: [ewlc-infra-evq] [19826]: (note): Authentication Success. Resolved Policy bitmap:15 for client XXXX.XXXX.XXXX

2025/02/17 08:33:15.594910729 {wncd_x_R0-0}{1}: [ewlc-infra-evq] [19826]: (ERR): SANET_AUTHC_FAILURE - AAA Server Down, audit session id XXXXXXXXXXXXXXXX

2025/02/17 08:33:15.594926484 {wncd_x_R0-0}{1}: [errmsg] [19826]: (note): %SESSION_MGR-5-FAIL: R0/0: wncd: Authorization failed or unapplied for client (XXXX.XXXX.XXXX) on Interface capwap_XXXX. Failure reason: Authc fail. Authc failure reason: AAA Server Down.

2025/02/17 08:33:15.594971575 {wncd_x_R0-0}{1}: [sanet-shim-miscellaneous] [19826]: (ERR): authc policy update from SANet vlan 0

2025/02/17 08:33:15.595010552 {wncd_x_R0-0}{1}: [client-orch-state] [19826]: (note): MAC: XXXX.XXXX.XXXX Client state transition: S_CO_MACAUTH_IN_PROGRESS -> S_CO_ASSOCIATING

2025/02/17 08:33:15.595026368 {wncd_x_R0-0}{1}: [dot11] [19826]: (ERR): MAC: XXXX.XXXX.XXXX Failed to assoc failure tr state entry. Incorrect validation status value :1

2025/02/17 08:33:15.595142139 {wncd_x_R0-0}{1}: [dot11] [19826]: (ERR): MAC: XXXX.XXXX.XXXX Dot11 update co assoc fail. Sent assoc failure to CO. delete reason: 9, CO_CLIENT_DELETE_REASON_MAB_FAILED

2025/02/17 08:33:15.595166908 {wncd_x_R0-0}{1}: [client-orch-sm] [19826]: (note): MAC: XXXX.XXXX.XXXX Client delete initiated. Reason: CO_CLIENT_DELETE_REASON_MAB_FAILED

2025/02/17 08:33:15.595210879 {wncd_x_R0-0}{1}: [client-orch-sm] [19826]: (note): MAC: XXXX.XXXX.XXXX Delete mobile payload sent for BSSID: XXXX.XXXX.XXXX WTP mac: XXXX.XXXX.XXXX slot id: 1

2025/02/17 08:33:15.595215493 {wncd_x_R0-0}{1}: [client-orch-state] [19826]: (note): MAC: XXXX.XXXX.XXXX Client state transition: S_CO_ASSOCIATING -> S_CO_DELETE_IN_PROGRESS

2025/02/17 08:33:15.595292681 {wncd_x_R0-0}{1}: [sanet-shim-translate] [19826]: (note): MAC: XXXX.XXXX.XXXX Session manager disconnect event called, session label: XXXXXXXXXX

2025/02/17 08:33:15.596282757 {wncd_x_R0-0}{1}: [client-orch-state] [19826]: (note): MAC: XXXX.XXXX.XXXX Client state transition: S_CO_DELETE_IN_PROGRESS -> S_CO_DELETED

2025/02/17 08:33:15.656092284 {wncd_x_R0-0}{1}: [apmgr-db] [19826]: (ERR): XXXX.XXXX.XXXX failed to retrieve radio aid record for slot 2, tdl err:0

2025/02/17 08:33:15.656317169 {wncd_x_R0-0}{1}: [client-orch-state] [19826]: (note): MAC: XXXX.XXXX.XXXX Client state transition: S_CO_INIT -> S_CO_ASSOCIATING

2025/02/17 08:33:15.656523888 {wncd_x_R0-0}{1}: [client-orch-state] [19826]: (note): MAC: XXXX.XXXX.XXXX Client state transition: S_CO_ASSOCIATING -> S_CO_MACAUTH_IN_PROGRESS

2025/02/17 08:33:15.656541943 {wncd_x_R0-0}{1}: [client-auth] [19826]: (note): MAC: XXXX.XXXX.XXXX MAB Authentication initiated. Policy VLAN 21, AAA override = 1, NAC = 1

 

We would appreciate any insights or recommendations on resolving this issue.

 

 

 

6 Replies 6

@aya24 

 I would recommend to check the ACL. Mac filter alone is not enough. The guide belew can help you double check all your config. 

 

ip access-list extended REDIRECT
deny ip any host <ISE-IP>
deny ip host<ISE-IP> any
deny udp any any eq domain
deny udp any eq domain any
permit tcp any any eq 80

https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/213920-central-web-authentication-cwa-on-cata.html

 

Arne Bier
VIP
VIP

Your issue might be a combination of factors - there are very good guides on the web on how to configure this stuff.

One thing that often catches people out is the URL redirection mechanism. On the 9800 it requires the line

ip http server

which looks bad from a security point of view, and therefore people tend to disable that. It is mandatory for the 9800 to allow URL interception and redirection. If you want to secure the 9800's Admin web UI (and disable http access to only allow https access) then there are different (more specific) commands to do that.

AAA Server Down <<- server dead???

There is connection issue I think.

Try do test aaa from wlc' 

Check aaa server dead criteria.

Share 

Show aaa dead criteria radius 

Show aaa servers | s wncd 

MHM

aya24
Level 1
Level 1

Thank you for your reply. The problem is not solved yet. We are going to upgrade the firmware from 17.14 to 17.16 and see if that helps.

By the way, I had ALC, and the ISE server is up—we still have our old environment running on it. As mentioned, the new WLC can communicate with ISE when using WPA2 only as a RADIUS server. However, there seems to be a bug since the client is getting an IP address from another VLAN, which was very strange. Therefore, we decided to upgrade the WLC firmware, as we read that there are some known bugs in the current version.

By the way, I want to make sure about the ACL. Should the ACL be assigned to a VLAN, or is it enough to just create it if we are not using Flex?

 

Regrads

By the way, I want to make sure about the ACL. Should the ACL be assigned to a VLAN, or is it enough to just create it if we are not using Flex?
ACL redirect ? you meaning ? If Yes then not need to assign it to WLAN/VLAN 
only add it to WLC 
make sure the name is same in WLC and ISE

MHM

I had no issues with guest on 17.14.1 release.

The ACL is not tied to the client VLAN. The VLAN that the client traffic ends up on is one that should have a DHCP scope for these guest clients devices. They must get IP address before the redirect even can take place. The ACL on the WLC ensures that the redirect happens to ISE CWA portal.