11-03-2023 12:52 AM
Hi!
Have you encountered in WLC 9800 that a wireless user is unable to redirect to client provisioning portal of ISE? based on logs the user is successfully authenticated and supposed to be redirected but it isn't happening. This is supposed to be be a migration from old WLC and the existing WLC have no problem with it.
11-03-2023 01:39 AM
- Checkout https://logadvisor.cisco.com/logadvisor/wireless/9800/9800CWA for further troubleshooting ,
M.
11-07-2023 04:34 AM
> user is successfully authenticated and supposed to be redirected
Normally a client is only redirected before authentication. Once they're authenticated they should be in run state with no redirect. Why would you want to redirect them after authentication?
What does "sh wireless client mac <client mac> detail" show?
Have you collected radioactive trace on client MAC?
Is you WLC software version up to date as per TAC recommended - link below?
11-08-2023 12:37 AM - edited 11-08-2023 12:48 AM
after authentication, should be redirected to client provisioning portal to:
1. download anyconnect for posture compliance OR
2. once have anyconnect start the posture assessment
on the sh wireless client mac <client mac> detail" its show the redirected url:
Server Policies:
URL Redirect ACL : WLAN-ISE-POSTURE
URL Redirect : https://<IP ADD>:8443/portal/gateway?sessionId=F064A8C0000001ABAE0CDCB5&portal=a6bb0db0-2230-11e6-99ab-005056bf55e0&action=cpp&token=11ce78e69d88e8606c5ecdf66bd1c5d7
VLAN : 240
Resultant Policies:
URL Redirect ACL : WLAN-ISE-POSTURE
URL Redirect : https://<IP ADD>:8443/portal/gateway?sessionId=F064A8C0000001ABAE0CDCB5&portal=a6bb0db0-2230-11e6-99ab-005056bf55e0&action=cpp&token=11ce78e69d88e8606c5ecdf66bd1c5d7
VLAN Name : quarantine
VLAN : 240
but the url doesn't pop-out upon connecting to SSID
11-08-2023 02:58 AM
But what is the client Policy Manager State at that point (which is why I wanted to see the detail)?
How is the client being "authenticated"?
If it's passed authentication and in Run state then I don't think the redirect will be applied by the controller because the client is authenticated. Any post-auth redirect should normally be done by the portal web page not by the controller.
11-08-2023 06:47 AM
11-08-2023 07:47 AM
- Below you will find the output of the debugTrace when analyzed with : https://cway.cisco.com/tools/WirelessDebugAnalyzer/
Connection attempt #1 | |||
2023/11/08 12:48:59.543 | client-iplearn | Client got IP: 192.168.240.23, discovered through: DHCP | |
2023/11/08 12:48:59.544 | client-auth | Initiated Central Web Auth process | |
2023/11/08 12:49:20.634 | client-orch-sm | Controller initiated client deletion with code: CO_CLIENT_DELETE_REASON_IP_DOWN_NO_IP. Explanation: Client sent a DHCP release IP address. Actions: This can be normal scenario depending on client behavior | |
Connection attempt #2 | |||
2023/11/08 12:49:20.761 | client-orch-sm | Client roamed to a new AP/BSSID: BSSID dcf7.1905.00c2, WLAN Sasuke, Slot 0 AP dcf7.1905.00c0, APDCF7.1904.2868 | |
2023/11/08 12:49:20.761 | dot11 | Association success for client, assigned AID is: 2 | |
2023/11/08 12:49:21.110 | client-auth | Starting EAPOL 4-Way Handshake | |
2023/11/08 12:49:21.122 | client-keymgmt | Negotiated the following encryption mechanism: AKM:DOT1X Cipher:CCMP WPA Version: WPA2 | |
2023/11/08 12:49:21.123 | client-orch-state | Starting Mobility Anchor discovery for client | |
2023/11/08 12:49:21.124 | client-orch-state | Entering IP learn state | |
2023/11/08 12:49:22.157 | client-iplearn | Client got IP: 192.168.240.23, discovered through: DHCP | |
2023/11/08 12:49:22.159 | client-auth | Initiated Central Web Auth process | |
2023/11/08 12:49:43.208 | client-orch-sm | Controller initiated client deletion with code: CO_CLIENT_DELETE_REASON_IP_DOWN_NO_IP. Explanation: Client sent a DHCP release IP address. Actions: This can be normal scenario depending on client behavior | |
Connection attempt #3 | |||
2023/11/08 12:49:43.328 | client-orch-sm | Client roamed to a new AP/BSSID: BSSID dcf7.1905.00cd, WLAN Sasuke, Slot 1 AP dcf7.1905.00c0, APDCF7.1904.2868 | |
2023/11/08 12:49:43.329 | dot11 | Association success for client, assigned AID is: 2 | |
2023/11/08 12:49:43.610 | client-auth | Starting EAPOL 4-Way Handshake | |
2023/11/08 12:49:43.624 | client-keymgmt | Negotiated the following encryption mechanism: AKM:DOT1X Cipher:CCMP WPA Version: WPA2 | |
2023/11/08 12:49:43.624 | client-orch-state | Starting Mobility Anchor discovery for client | |
2023/11/08 12:49:43.625 | client-orch-state | Entering IP learn state | |
2023/11/08 12:49:59.898 | client-iplearn | Client got IP: 192.168.240.23, discovered through: DHCP | |
2023/11/08 12:49:59.899 | client-auth | Initiated Central Web Auth process | |
2023/11/08 12:50:20.989 | client-orch-sm | Controller initiated client deletion with code: CO_CLIENT_DELETE_REASON_IP_DOWN_NO_IP. Explanation: Client sent a DHCP release IP address. Actions: This can be normal scenario depending on client behavior | |
Connection attempt #4 | |||
2023/11/08 12:50:21.074 | client-orch-sm | Client roamed to a new AP/BSSID: BSSID dcf7.1905.00c2, WLAN Sasuke, Slot 0 AP dcf7.1905.00c0, APDCF7.1904.2868 | |
2023/11/08 12:50:21.075 | dot11 | Association success for client, assigned AID is: 2 | |
2023/11/08 12:50:21.415 | client-auth | Starting EAPOL 4-Way Handshake | |
2023/11/08 12:50:21.431 | client-keymgmt | Negotiated the following encryption mechanism: AKM:DOT1X Cipher:CCMP WPA Version: WPA2 | |
2023/11/08 12:50:21.431 | client-orch-state | Starting Mobility Anchor discovery for client | |
2023/11/08 12:50:21.432 | client-orch-state | Entering IP learn state | |
2023/11/08 12:50:36.205 | client-iplearn | Client got IP: 192.168.240.23, discovered through: DHCP | |
2023/11/08 12:50:36.206 | client-auth | Initiated Central Web Auth process | |
2023/11/08 12:50:57.301 | client-orch-sm | Controller initiated client deletion with code: CO_CLIENT_DELETE_REASON_IP_DOWN_NO_IP. Explanation: Client sent a DHCP release IP address. Actions: This can be normal scenario depending on client behavior | |
Connection attempt #5 | |||
2023/11/08 12:50:57.477 | client-orch-sm | Client roamed to a new AP/BSSID: BSSID dcf7.1905.00cd, WLAN Sasuke, Slot 1 AP dcf7.1905.00c0, APDCF7.1904.2868 | |
2023/11/08 12:50:57.477 | dot11 | Association success for client, assigned AID is: 2 | |
2023/11/08 12:50:57.787 | client-auth | Starting EAPOL 4-Way Handshake | |
2023/11/08 12:50:57.799 | client-keymgmt | Negotiated the following encryption mechanism: AKM:DOT1X Cipher:CCMP WPA Version: WPA2 | |
2023/11/08 12:50:57.799 | client-orch-state | Starting Mobility Anchor discovery for client | |
2023/11/08 12:50:57.801 | client-orch-state | Entering IP learn state | |
2023/11/08 12:51:12.451 | client-iplearn | Client got IP: 192.168.240.23, discovered through: DHCP | |
2023/11/08 12:51:12.452 | client-auth | Initiated Central Web Auth process | |
2023/11/08 12:51:33.525 | client-orch-sm | Controller initiated client deletion with code: CO_CLIENT_DELETE_REASON_IP_DOWN_NO_IP. Explanation: Client sent a DHCP release IP address. Actions: This can be normal scenario depending on client behavior | |
Connection attempt #6 | |||
2023/11/08 12:51:34.789 | client-orch-sm | Client roamed to a new AP/BSSID: BSSID dcf7.1905.00c2, WLAN Sasuke, Slot 0 AP dcf7.1905.00c0, APDCF7.1904.2868 | |
2023/11/08 12:51:34.789 | dot11 | Association success for client, assigned AID is: 2 | |
2023/11/08 12:51:35.152 | client-auth | Starting EAPOL 4-Way Handshake | |
2023/11/08 12:51:35.167 | client-keymgmt | Negotiated the following encryption mechanism: AKM:DOT1X Cipher:CCMP WPA Version: WPA2 | |
2023/11/08 12:51:35.167 | client-orch-state | Starting Mobility Anchor discovery for client |
11-08-2023 08:42 AM
> Policy Manager State: Webauth Pending
So in that case, agreed that the client should get redirected (at that point they are not authenticated as far as I'm concerned)
Does your pre-auth ACL allow access to 192.168.100.249:8443?
"VLAN Name: quarantine" - does the quarantine VLAN have connectivity to 192.168.100.249?
So next step - packet capture on the client to see whether they get the redirect and what happens next.
You should see the client sending http://<something> which gets redirected to ISE and then the client should attempt to connect to ISE.
Do you have a valid trusted certificate installed on ISE? If not then the client will not be able to establish a TLS connection with ISE and the redirect will fail. The fact that you are redirecting to an IP address and not a domain name immediately makes me suspicious that you have not setup the certificate correctly. You should have a trusted certificate with a DNS domain name which matches the certificate and you should be redirecting to the domain name not an IP address.
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