Troubleshoot Cisco CWA effectively by identifying exactly where the redirection breaks, as it remains one of the most common tickets in a wireless engineer’s queue. While Central Web Authentication (CWA) should be seamless, a single misconfiguration in the Redirect ACL or an ISE Policy-Result can bring the whole process to a halt. In this guide, we’ll look at the 11 most common reasons your Cisco CWA redirect isn’t working—and, more importantly, the TAC-level fixes required to get your guests back online.
Scenario 1: RADIUS Traffic Drop (Unknown Network Device)
The Symptom: Your client connects to the SSID, but the redirect never happens. When you check the ISE Live Logs, you see a sea of red or—even worse—absolutely nothing at all.
Short Description: The WLC is sending authentication requests, but ISE is silently dropping the traffic because it doesn’t recognize the 9800 WLC as a trusted client.
1. The Evidence (ISE Live Logs)
When this issue occurs, do not just look for a “Reject”—ISE will often not log a standard failure if it doesn’t trust the source. Instead, look for the following specific entry in the Live Log for an Unknown NAD, ensuring you filter around the exact timestamp of your testing:
2. The Root Cause
This is typically a “Day 0” configuration oversight. ISE will only respond to RADIUS packets from IP addresses defined in its internal database.
The Missing Entry: The Catalyst 9800 WLC hasn’t been added under Administration > Network Resources > Network Devices.
The IP Mismatch: The WLC is added, but it is sending traffic from a different interface (e.g., a Service Port or a different VLAN) than the one configured in ISE.
3. The Solution & Verification
Step A: Check the ISE Configuration
Navigate to Administration > Network Resources > Network Devices and ensure your WLC’s IP address matches the source IP of the RADIUS packets.
Step B: Verify & Correct the WLC Source Interface
On the Catalyst 9800, you must explicitly tell the WLC which interface to use for RADIUS traffic. If this is not defined, the WLC may select an interface (like the Management or Service port) that ISE does not recognize, leading to the 11007 Error.
1. Verification
Run the following commands to check your current configuration and available paths:
# Verify if the correct interface is mentioned under the radius group
show run | sec group
# If the interface is missing or wrong, check your available IP interfaces
show ip interface brief
2. Applying the Fix
If the source interface is incorrect or missing, apply the fix directly under your RADIUS server group:
conf t
aaa group server radius <Group-Name>
ip radius source-interface <Vlan/GigabitEthernet>
exit
💡Pro-Tip: It is highly recommended to apply the
ip radius source-interfacecommand under each specific group rather than globally. This provides granular control and makes troubleshooting much easier in multi-VLAN environments where different traffic types may need different exit points.
Scenario 2: Shared Secret Key Mismatch
The Symptom: Similar to Scenario 1, the WLC appears to be sending traffic, but ISE isn’t processing the authentication. However, unlike a missing NAD, the traffic is reaching ISE, but ISE simply cannot “read” it.
Short Description: The RADIUS packet arrives at ISE, but because the shared secret keys do not match, ISE cannot validate the Message-Authenticator attribute and drops the request.
1. The Evidence (ISE Live Logs)
Look for this specific failure code in your ISE Live Logs. It is a clear indicator of an encryption/decryption failure:
| Event | 5405 RADIUS Request dropped |
| Failure Reason | 11036 The Message-Authenticator RADIUS attribute is invalid |
2. The Root Cause
The shared secret configured on the Catalyst 9800 WLC does not match the one configured in ISE under the Network Device settings. Even a single misplaced character or trailing space will cause the hash to fail.
3. The Solution & Troubleshooting
Step A: Synchronize the Keys
On ISE: Navigate to Administration > Network Resources > Network Devices. Re-type the shared secret and save.
On WLC: Update the radius key in plain text to ensure no copy-paste errors occurred.
Step B: Rule out Special Character Defects
If the issue persists, avoid using complex special characters (like #, ?, or !) temporarily. Test with a simple alphanumeric key (e.g., Support123) to rule out any software defects or parsing issues on either the WLC or ISE side.
4. Advanced Verification (The Wireshark Method)
If you are still seeing the 11036 error after updating the keys, it’s time to prove where the mismatch is. Perform a TCP dump (packet capture) on the ISE node or the network path and open it in Wireshark.
Go to Edit -> Preferences -> Protocols -> RADIUS.
Enter your Shared Secret in the field.
If the key is correct, Wireshark will be able to successfully decrypt and decode the RADIUS AVPs.
If Wireshark cannot decode the traffic, then the WLC is sending traffic with a key that does not match what you think it is.
Scenario 3: MAB Authentication Failed – Wrong Authorization Policy Match
The Symptom: The client connects to the SSID, but instead of seeing the Guest Portal, they are immediately disconnected or hit a “Deny Access” page. In the ISE Live Logs, you see the client matching the wrong rule (often the “Default” rule) instead of your Guest Redirect.
Short Description: The client’s request is hitting an incorrect Authorization Policy or failing the MAB authentication step because ISE is not configured to “Continue” when a new guest MAC address is encountered.
1. Root Cause Analysis
Policy Set Mismatch: The initial request isn’t matching the correct Policy Set Condition (e.g., matching the wrong SSID or WLC IP).
Authentication “Stop”: Under Authentication Policy Options, ISE is set to “Reject” if a user is not found. Since new guests aren’t in the database yet, the process stops.
Logical Order Error: The Authorization rules are out of order, causing the client to bypass the Redirect rule or hit a “Deny” rule prematurely.
2. The Solution: Policy Hierarchy & Options
Step A: The MAB “Continue” Option
For CWA to work, ISE must be allowed to process “Unknown” MAC addresses.
Go to your Authentication Policy.
Under Options, ensure that “If user not found” is set to Continue (not Reject). This allows the flow to proceed to the Authorization Policy where the Redirect is handled.
Step B: Perfecting the Authorization Rule Order
Rules are processed from Top to Bottom. You must organize them so that the most specific “Success” state is at the top, and the “Initial Redirect” is at the bottom.
Recommended Order:
Reconnect/Cache Rule (Top): Checks if the endpoint was recently authenticated (e.g.,
LastAUPAcceptanceHours LESS 8). This allows returning guests to skip the portal.Guest Access Rule (Middle): This matches the “Guest Flow” attribute sent back after the user logs into the portal.
Guest Redirect Rule (Bottom): The “Catch-all” for new wireless MAB requests. This sends the
CWA_Redirectprofile to the client.
3. Configuration Example
Here is a visual breakdown of how your Authentication & Authorization Policy should look:
💡 Expert Tip:The “Guest Cache” Advantage
Implementing a Guest Cache (Rule 1) is a major “Quality of Life” improvement for your users. Its primary job is to provide a “Fast-Pass” for devices that have already authenticated.
Sleep Mode: Prevents users from being forced to re-accept the AUP (Acceptable Use Policy) every time their phone “sleeps” and disconnects to save battery.
Roaming Issues: Ensures a seamless experience if a user roams between Access Points, especially in cases where roaming is not perfectly seamless or the session is being interrupted/re-interpreted by the WLC during a transition.
By checking the EndPoint-LastAUPAcceptanceHours attribute, you ensure that as long as they agreed to your terms within the last 8 (or 12) hours, they stay connected without seeing the portal again.
Scenario 4: ISE Attributes Not Applied (The Redirect Fail)
The Symptom: Your ISE Live Logs show a perfect “Success” with the CWA_Redirect profile being sent. However, the client device behaves as if it’s on a normal open network—no portal appears, and they have unrestricted access or no connectivity.
Short Description: The client matches the correct MAB Authorization Policy, but the Redirect ACL and URL are not being applied to the client session on the WLC.
Case 1: ISE Attributes Discarded by WLC (Client Session Active)
1. The Evidence: Checking the WLC Client Detail
To confirm if the WLC is actually receiving and applying the ISE attributes, you need to look at the Server Policies section for that specific client.
Observation in WLC GUI:
Navigate to Monitoring > Wireless > Client > General > Security Information. If the Server Policies section is empty, the WLC has discarded the instructions sent by ISE
Observation in WLC CLI:
To see exactly what the WLC is doing with the ISE instructions, run the following command and scroll down to the Server Policies section:
# Check the specific client session details
show wireless client mac-address <xxxx.xxxx.xxxx> detail
If the attributes are NOT being applied, your output will look like this:
Local Policies:
Service Template : wlan_svc_LAB-Access_local (priority 254)
VLAN : Sof-Wireless-Vlan103
Absolute-Timer : 36000
Server Policies:
<empty>
Resultant Policies:
VLAN Name : Sof-Wireless-Vlan103
VLAN : 103
Absolute-Timer : 36000
Note: If you see
<empty>under Server Policies, the WLC has ignored the Redirect-URL and Redirect-ACL sent by ISE.
2. The Root Cause
The Catalyst 9800 WLC is a “Security First” platform. By default, it will not allow an external server (ISE) to override its local policy profile unless you explicitly give it permission to do so.
3. The Solution: Enable AAA Override
You must enable AAA Override within the specific Policy Profile attached to your SSID to allow ISE to “push” the redirect parameters.
Option A: GUI Configuration
Navigate to Configuration > Tags & Profiles > Policy.
Select your Policy Profile (e.g., LAB-Access).
Go to the Advanced tab.
Under the AAA Policy section, check the box for Allow AAA Override.
Option B: CLI Configuration
If you prefer the command line, apply the following changes to your policy profile:
# Enter configuration mode
conf t
# Enter the specific wireless policy profile
wireless profile policy <LAB-Access>
aaa-override
nac
exit
Case 2: Redirect ACL Mismatch
The Symptom: ISE shows a successful authentication (Green Live Log) and correctly sends the url-redirect-acl attribute. However, on the WLC side, the client session is abruptly destroyed.
Short Description: The WLC receives the name of an ACL from ISE, but it cannot find a locally configured ACL that matches that exact string. As a result, the WLC rejects the policy application.
1. Root Cause: Case Sensitivity & Typos
The 9800 WLC is extremely strict. If ISE sends Guest_Redirect but the ACL on the WLC is named GUEST_REDIRECT or Guest-Redirect, the WLC will fail to map the attribute. Client session is destroyed because AAA Override is enabled on the WLAN, the WLC is forced to enforce the policy sent by ISE. When the WLC fails to find the local ACL name sent in the RADIUS VSA, an AVP (Attribute-Value Pair) installation failure occurs. This creates a security mismatch; the WLC cannot fulfill the “contract” sent by AAA, so it terminates the client session entirely rather than allowing an un-policed connection.
2. The Solution: Naming Alignment
Step 1: Check ISE (The “Sender”)
You must find the exact string the WLC is receiving.
Navigate to Policy > Policy Elements > Results > Authorization Profiles.
Find and click on your Redirect Profile (e.g.,
CWA_Redirect).Scroll down to the Attributes Details section.
Look for the
cisco-av-pairthat defines the ACL.Example:
url-redirect-acl=WebAuth_Redirect_ACL
Note: Pay extremely close attention to underscores
_, dashes-, and capitalization.WebAuth-ACLis not the same aswebauth-acl.
Step 2: Check WLC (The “Receiver”)
Now, verify that this exact name exists in the WLC’s global configuration.
Log into the Cisco Catalyst 9800 GUI.
Navigate to Configuration > Security > ACL.
Look for the ACL name in the list. It must match the ISE string character-for-character.
Scenario 5: DHCP or DNS Failure (The “No Connectivity” Block)
The Symptom: The client connects to the SSID but sits with a “No Internet” or “Connecting…” status indefinitely. The Captive Network Assistant (CNA) browser never pops up.
Short Description: The client is unable to obtain an IP address via DHCP or fails to resolve the FQDN for the connectivity check. This causes all Layer 3 traffic to stall, and the guest flow fails before it even starts.
1. Root Cause Analysis
Without a valid IP address and working DNS, the client cannot communicate with the WLC’s virtual interface or the ISE portal.
DHCP Exhaustion: The guest pool is full, or the DHCP relay (IP Helper) is misconfigured.
DNS Blockage: The Redirect ACL is accidentally blocking DNS traffic, preventing the client from resolving the “Connectivity Check” URL (like
captive.apple.com).
2. The Solution: Step-by-Step Infrastructure Check
Step A: Troubleshoot the DHCP Handshake
Verify if DHCP traffic is reaching your server and ensure you aren’t suffering from DHCP Starvation (exhausted pools).
Cisco has an excellent deep-dive guide specifically for this on the 9800:
Troubleshoot DHCP Client Connectivity Issue on a Cisco 9800 WLC
Step B: Verify DNS & Redirect ACL Logic
In a 9800 Redirect ACL, you must deny the traffic you want the WLC to “ignore” (let through) and permit the traffic you want to “intercept” (redirect to portal).
If you don’t “deny” DNS (UDP 53), the WLC will try to redirect the DNS query itself to the portal, which will obviously fail.
Correct Redirect ACL Structure:
# Enter the Redirect ACL configuration
ip access-list extended <Redirect-ACL-Name>
# 1. Allow traffic to ISE (Don't redirect portal traffic)
deny ip any host <ISE-IP>
deny ip host <ISE-IP> any
# 2. Allow DNS (Crucial: Don't redirect DNS queries!)
deny udp any any eq domain
deny udp any eq domain any
# 3. Redirect everything else (HTTP/HTTPS) to the portal
permit ip any anyScenario 6: Untrusted Certificate Warning (The HTTPS Intercept Issue)
The Symptom: When a guest client connects and tries to browse to an HTTPS website, they receive a “Your connection is not private” or “Untrusted Certificate” warning. The browser shows that the WLC is presenting its own certificate instead of the certificate of the website the user is trying to reach.
Short Description: The WLC is attempting to intercept encrypted HTTPS traffic to trigger the redirect. Because it cannot technically “impersonate” every website on the internet, the browser identifies this as a Man-in-the-Middle (MITM) behavior and blocks the page.
1. Root Cause: The HTTPS Intercept Trap
Modern browsers (Chrome, Safari, etc.) are designed to prevent exactly what the WLC is trying to do. If the WLC intercepts an HTTPS request:
The TLS tunnel is established between the Client and the WLC, not the destination website.
The WLC presents its certificate (which has its own FQDN/SAN).
The browser detects that the certificate name does not match the website URL (e.g.,
google.com) and throws a security error.
The Fix: Redirection should ideally happen over HTTP, which allows the WLC to inject the redirect URL without triggering a TLS handshake error.
2. The Solution: Disable HTTPS Interception
To provide a seamless experience where the Captive Portal pops up automatically (via the CNA), you should configure the WLC to use HTTP for the initial intercept.
Option A: GUI Configuration
Navigate to Configuration > Security > Web Auth > Global > General Tab:
Disable “Web Auth intercept HTTPS”
Enable “Enable HTTP server for Web Auth”
Enable “Disable HTTP secure server for Web Auth”
Option B: CLI Configuration
Apply these commands to the global parameter map to force the intercept logic toward HTTP:
parameter-map type webauth global
no intercept-https-enable
webauth-http-enable
secure-webauth-disable3. Why this works
By disabling HTTPS interception, the client’s device will use its background “Connectivity Check” (which is usually an HTTP request to a site like www.msftconnecttest.com or captive.apple.com) to trigger the redirect. This avoids the certificate warning entirely and allows the Captive Network Assistant (CNA) to pop up smoothly.
💡 Expert Tip: Why a Signed Certificate Won’t Fix HTTPS Interception
Even if you have a 3rd-party signed certificate (from a Public CA like DigiCert or Let’s Encrypt) installed on your WLC, you should still disable HTTPS intercept.
The Technical Reality: A valid certificate only prevents the warning for the WLC’s own portal page (e.g., guest.yourcompany.com). It does NOT allow the WLC to intercept other HTTPS websites (like google.com or apple.com) without a browser error.
Why? 1. Ownership & SAN: The WLC does not own the other site. The Subject Alternative Name (SAN) on its certificate is only valid for its own FQDN. 2. Authorization: The WLC is not authorized to present itself as any other website. When it tries to intercept an encrypted session, the client’s browser detects the name mismatch immediately. 3. TLS Integrity: This is the core foundation of the TLS protocol. It is a security mechanism designed specifically to prevent Man-in-the-Middle (MITM) attacks and cannot be bypassed. If a client trusted a WLC presenting a different SAN, it would be a catastrophic security risk.
Conclusion: To ensure a smooth Guest experience, always redirect using HTTP. This allows the device to trigger the portal before a secure tunnel is even attempted.
Scenario 7: Client Not Redirected to ISE Guest Authentication Page
The Symptom: The client successfully resolves a “Connectivity Check FQDN” (via DNS), completes the TCP 3-way handshake, and sends an HTTP GET packet. However, instead of receiving a redirect to ISE, the client either reaches the actual destination or receives a standard HTTP 200 OK response that does not contain the ISE redirect URL.
Short Description: The Layer 3 interception is failing. The WLC is allowing the traffic to pass through to the internet instead of hijacking the session and pointing it to the ISE Portal.
Case 1: Redirect ACL Logic Issue
In this case, the Redirect ACL is configured, but it is permitting the traffic to exit the WLC instead of intercepting it.
1. Root Cause
The WLC is not intercepting the traffic; the original destination is replying instead of the Catalyst 9800. This happens because the ACL is not telling the CPU to “Punt” the traffic for redirection.
2. The Solution: Correcting ACL Logic
In a 9800 (IOS-XE) redirect ACL, the logic is different than standard ACLs:
deny= Do NOT redirect (Pass-through traffic, like DNS or ISE traffic).permit= Intercept and Redirect to the portal.
Verify your CLI configuration:
ip access-list extended WebAuth-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 ip any any <-- This "Permit" triggers the redirect
Logic Alert: In a redirect ACL, a
denystatement means “allow the traffic to pass through.” Apermitstatement means “process at the CPU level and redirect the traffic.”
Case 2: HTTP Services Not Running on WLC
Even with a perfect ACL, the WLC cannot redirect traffic if its internal HTTP engine is turned off.
1. Root Cause
HTTP services are disabled globally on the WLC or specifically within the “global” parameter map. This is common in high-security environments where admins disable HTTP by default.
2. The Solution: Enable Web Auth HTTP Services
You must enable HTTP services specifically for guest flow.
GUI Configuration:
Navigate to Configuration > Security > Web Auth.
Go to the Global > General Tab.
Ensure “Enable HTTP Server for Web Auth” is checked.
CLI Configuration:
no ip http server
ip http secure-server
# Enable specifically for WebAuth
parameter-map type webauth global
webauth-http-enableScenario 8: ISE FQDN DNS Resolution Failure
The Symptom: The client receives the Redirect URL (verified in WLC client details), but the browser shows “Server Not Found” or “DNS_PROBE_FINISHED_NXDOMAIN” when trying to load the portal.
Short Description: The client can reach the internet, but it cannot translate the ISE Fully Qualified Domain Name (FQDN) into an IP address.
1. Root Cause
Missing Records: The DNS server assigned to the Guest VLAN does not have an A Record for the ISE PSN.
Split-Horizon DNS: The client is using a Public DNS (like 8.8.8.8), but the ISE FQDN is only defined on the Internal DNS server.
2. The Solution
Verify Client DNS: On the client device, confirm it has received the correct DNS server via DHCP.
DNS Entry: Ensure the ISE FQDN (e.g.,
ise-psn01.company.com) is reachable and resolvable from the Guest Network.The Test: From a test machine on the Guest VLAN, try to
nslookupthe ISE FQDN. If it fails, the portal will never load.
💡 Expert Tip: DNS Strategy & The Load Balancer Trap
For the best guest experience, it is often best to use a Publicly Resolvable FQDN for ISE. This avoids the common issue where guests using public DNS (like Google 8.8.8.8 or Cloudflare 1.1.1.1) cannot resolve your internal ISE names.
However, using a single public FQDN for multiple ISE nodes usually requires a Load Balancer (LB), which introduces its own set of complexities:
ISE vs. Load Balancers: ISE is notoriously sensitive to how Load Balancers handle traffic.
Persistence is Key: Load balancing must be configured per session, not per packet. If a client starts a 3-way handshake with
PSN-01but the LB sends the next packet toPSN-02, the TCP session will reset, and the portal will fail to load.Session Integrity: Ensure your LB uses “Sticky Sessions” (Source IP persistence) to maintain the communication path between the guest client and the specific ISE node throughout the entire portal flow.
Scenario 9: Client Unable to Open ISE Portal Page (TCP Session Issue)
The Symptom: The client has successfully resolved the ISE FQDN (passing Scenario 8), but the browser eventually times out with a “Connection Timed Out” error. The TCP SYN packet is not reaching the ISE Policy Service Node (PSN) over the required guest portal port—typically 8443 or a custom ID.
Short Description: While DNS resolution is successful, a TCP session cannot be established between the client and the ISE PSN.
1. Root Cause
Traffic between the client and ISE is being blocked specifically over the guest portal port. This is often due to:
Redirect ACL Omissions: A specific PSN IP address was left out of the redirect ACL.
Upstream Security: A physical firewall or an intermediate network ACL is dropping the traffic to the ISE PSN nodes.
2. The Solution: Comprehensive Redirect ACL
Verify that the redirect ACL on the WLC includes all ISE PSN IP addresses as deny statements (meaning “do not redirect this traffic; let it pass through to ISE”). If a node is missing, the WLC will try to redirect the portal traffic to itself, causing a loop and a timeout.
Update your ACL to include all nodes:
# Update the Redirect ACL to include all ISE PSN nodes
ip access-list extended WebAuth-Redirect
deny ip any host <ISE-PSN1>
deny ip host <ISE-PSN1> any
deny ip any host <ISE-PSN2>
deny ip host <ISE-PSN2> any
# Repeat for additional PSNs if necessary
# Ensure DNS is allowed (Pass-through)
deny udp any any eq domain
deny udp any eq domain any
# Intercept remaining traffic for redirection
permit ip any anyScenario 10: TLS Handshake Issue (The “Certificate Not Trusted” Loop)
The Symptom: The client is successfully redirected to the ISE Portal URL. However, the browser either stops with a “Your connection is not private” error or, more commonly now, shows a blank screen with no option to proceed. The Captive Network Assistant (CNA) on mobile devices may simply disappear or fail to trigger the login button.
Short Description: The client’s browser cannot verify the ISE PSN’s identity. Because of modern security protocols, the browser often “hard blocks” the page, preventing the user from even seeing the “Proceed anyway” option.
1. Root Cause: Trust Chains and Browser Enforcement
Internal CA: ISE is using a certificate signed by an internal Microsoft CA. Guest devices do not have this Root CA in their trusted store.
HSTS (HTTP Strict Transport Security): If the domain ISE is using (e.g.,
company.com) is on the HSTS preload list, browsers will not allow a user to click “Proceed” on a certificate error. The request is blocked instantly for the user’s protection.Self-Signed Certificates: These are almost always blocked by modern mobile OSs (iOS/Android) without an option to bypass, leaving the client stuck on a loading screen.
2. The Solution: Use a Publicly Signed Certificate
For Guest/BYOD flows, a Public CA certificate (e.g., DigiCert, Sectigo, Let’s Encrypt) is mandatory. Guests already have these Public Root CAs pre-installed on their devices.
Checklist for the ISE Certificate:
Public Trust: Ensure the portal certificate is signed by a Public CA.
SAN (Subject Alternative Name) Strategy: The ISE FQDN and the Guest URL (if using a public DNS/Load Balancer FQDN) must match the SAN field of the certificate. If you are using a single certificate for multiple PSNs, ensure all PSN FQDNs are listed as SAN entries.
Complete Chain: Always upload the Intermediate CA along with the identity certificate to ISE. Mobile devices often fail to resolve the chain if the server doesn’t provide it.
3. Verification
Ensure the Redirect-URL sent by the WLC matches the FQDN on your public certificate:
# Verify the redirect URL matches your Public Certificate FQDN
show wireless client mac-address <xxxx.xxxx.xxxx> detail | include Redirect-URL
💡 Expert Tip: The “Invisible” Block
“Never use an Internal CA for Guest Portals. Even if you provide a link to ‘Download our Root Certificate,’ most guests find this suspicious and won’t do it. Furthermore, modern browsers often ‘hard block’ the request entirely without even offering the ‘Proceed to website’ option. This happens because the browser views an untrusted SAN or a missing Root CA as a high-risk security event. This leaves the client completely stuck—unable to authenticate, unable to see the portal, and unable to bypass the error. A $20 public certificate saves hundreds of hours in helpdesk tickets and ensures the TLS protocol works as intended without being blocked by aggressive browser security filters.”
Scenario 11: No Internet Access After Successful Web Portal Authentication
The Symptom: The guest user enters their credentials or accepts the AUP on the portal. ISE shows “Authentication Succeeded,” but the user remains stuck. They are either still redirected to the portal or have no internet access at all.
Short Description: The client is retaining outdated server policy attributes (Redirect ACL/URL). The WLC has not received or processed the “nudge” from ISE to re-authenticate the user and apply the “Permit Access” policy.
Case 1: CoA Failure / MAB Re-Authentication Not Triggered
In this case, ISE tells the WLC “This user is now authorized,” but the WLC ignores the message.
1. Root Cause
The Change of Authorization (CoA) is either disabled or misconfigured. Without CoA, the WLC doesn’t know it needs to terminate the “Redirect” session and start a new “Permit” session.
2. The Solution: Enable NAC and CoA Support
Step A: Enable NAC State in the Policy Profile The Policy Profile must be in “NAC” mode to allow ISE to trigger session changes.
GUI: Configuration > Tags & Profiles > Policy > [Your Profile] > Advanced. Check NAC State.
CLI:
wireless profile policy CWA-Policy aaa-override nac
Step B: Enable RADIUS CoA Globally Ensure the WLC is listening for CoA packets from ISE.
GUI: Configuration > Security > AAA > Servers/Groups > Radius > Servers. Ensure Support for CoA is ENABLED.
CLI:
aaa server radius dynamic-author client <ISE-PSN1-IP> server-key <shared-key> client <ISE-PSN2-IP> server-key <shared-key>
Case 2: CoA Successful, but Flow Loop (ISE Policy Issue)
In this case, the WLC does re-authenticate the user, but the user is sent right back to the start.
1. Root Cause
After the CoA triggers a second MAB authentication, the client still matches the Redirect rule in ISE instead of the Permit rule. This happens if the ISE Authorization Policy doesn’t have a specific condition to recognize the user has already passed the web portal (e.g., Network Access:UseCase Equals GuestFlow).
2. The Solution
Check your ISE Radius Live Logs. If you see two successful authentications in a row for the same MAC address, but both applied the “CWA_Redirect” profile, your ISE logic is stuck in a loop.
Fix: Ensure your “Permit Guest” rule is above your “Redirect Guest” rule and includes a condition like
Guest_Portal_Auth_Success.
💡 Expert Tip
“CoA issues are often caused by firewalls. Remember that while RADIUS uses ports 1812/1813 (WLC to ISE), CoA uses port 1700 (ISE to WLC). If port 1700 is blocked, your guests will be ‘trapped’ in the portal forever!”
💡 Pro-Tip: The “Post-Auth” Connectivity Delay
Even with a successful CoA and right MAB policy, some clients may show “No Internet” for 60+ seconds. This happens because the Client OS (Windows/Android/iOS) must first validate the connection via Connectivity Check FQDNs (like
msftconnecttest.com).If you use a Custom Success Page instead of the default ISE “Success” flag, the OS may miss the immediate “200 OK” signal from ISE. It will then wait for its next background probe cycle before it officially “unlocks” the interface for traffic. To minimize this, try to stick to default ISE success handles where possible.
Â
