ISE 2.3 WLC 5760 CWA issue

[Adam White]

Hi, 

I have an issue with CWA on the above mentioned devices. 

The redirect seems to have issues, the debug on the WLC shows the redirect URL is being sent, but I get this

May 23 10:00:53.387: WA-HTTPD: [10.11.4.58 ] fd=4 HTTP Intercept, session not found
May 23 10:00:53.391: WA-QLFY : Ca0 [10.11.4.58 ] Ingress qlfy, Session not found for source IP [10.11.4.58] mac [9c04.7388.7819], forward
May 23 10:00:53.394: WA-QLFY : Ca0 [10.11.4.58 ] Ingress qlfy, Session not found for source IP [10.11.4.58] mac [9c04.7388.7819], forward

It looks like for some reason the controller doesnt have the session, on the monitor clients I see the session and it is in webauth_Pend 

I dont get much when googling on the session not found log message

ISE 2.3 patch 3

WLC 5760  Version 03.07.05E

any ideas?

[ajc]

run in the wlc DEBUG CLIENT (CLIENT MAC) and post the results.

Is this a new implementation or it was working and suddenly failed?

[Adam White]

Hi 

This is a new deployment where we are having this issue

Regards

adam

[ajc]

Please post this as well

debug web-authredirect enable mac <client mac address>

[ajc]

Are you using flexconnect or this is a centralized deployment?

[Adam White]

Hi, 

It is central. 

Those are definitely configured and ticked as shown. 

Everything looks right except the controller having issues with the user session....

Might end up logging at TAC case 

[ajc]

Another issue that could be affecting you is the HTTPS redirect.

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/118826-config-https-webauth-00.html

[ajc]

From your debugs looks like WLC configuration is properly configured but doublecheck the following:

[ajc]

In addition to the previous, the connection is stuck on WEBAUTH_Reqd which could possible be a DNS misconfiguration, PRE_AUTH ACL not properly configured, not using the right port 8443 or FW in the middle not allowing URL redirect initiated by ISE. That's why I need also the output for:

 •debug web-authredirect enable mac <mac addr>

In any case, from Primary PAN, open the Guest portal being used in the AUTHZ redirect policy/rule, click on the Portal Test URL (a second browser must be displayed with no issues), copy the URL with IP instead of FQDN for the guest portal, paste that URL into the WLC SSID L3 redirect link and provide results. You should get a certificate warning on the enduser device but that does not matter at this point because we are only checking communication ISE/PSN to WLC recreating Webauth. See the next screenshot sequence as explanation.

[Adam White]

Hi, 

Thanks for all the responses, I will give it a try

Once on the guest SSID, If i paste the redirect URL into my browser I get to the guest portal, I do have issues with the tokens sometimes, but I can get there without a problem which means DNS is working and the firewall in between is allowing the traffic. 

I do not have a redirect URL configured on the controller at all, I assumed this would be sent via an AV pair from the ISE to the controller, but  I can try that as well. 

I will do the debug and see what the outputs are

Thanks!

[ajc]

Hi Adam,

The URL in the L3 tab of the WLC is only for testing purposes to verify that ISE provides the portal but we should not use it because as you said, that AV Pair should provide that URL Redirect information.

Another piece that sometimes is missed is the SUPPORT FOR COA enabled in the WLC Radius Authentication Server configuration without that, the WLC would not reinitialize the AUTHC and accept the new policy sent by ISE.

Important also to mention that the NAME of the Preauth ACL in the WLC must be the same you have in the AUTHZ Profile. That Preauth ALC should ONLY allow traffic between enduser and ISE+DNS+DHCP, nothing else. Once the Webauth is completed, then another AUTHZ policy would allow you internet access.

[Adam White]

Hi, 

This version of WLC software doesnt seem to have the COA under server groups -> Radius

With regards to the preauth ACL, I have utilized deny's for the DNS and ISE traffic and allow for http / https for redirection. 

Should I not have the HTTP / HTTPS in the ACL?

[ajc]

Hi Adam,

From the following link

https://www.cisco.com/c/en/us/support/docs/wireless/5700-series-wireless-lan-controllers/117717-config-wlc-00.html,

Looks like the option is located at CONFIGURATION --- > SECURITY --- > RADIUS --- > Servers -- > SUPPORT FOR RFC 3576

From the link above also, you DO NOT need to allow DHCP, DNS and ISE in the Preauth ACL of the WLC for WLC 5760 configuration. So only allowing port 80 and 443 should be enough. On my case, I have 5508 and the configuration is slightly different as indicated in the same link).

Take a look on this link. BUT, we aware the ISE is using STATIC IP/Hostname in the AUTHZ profile configuration and that is the reason because you do not need to allow DNS in the Preauth ACL of the WLC. I do not know how many ISE PSN's you have so that specific configuration example could need to be modified for you specific environment.

[Adam White]

Hi, 

I have included the debug to include the redirect

May 25 11:01:54.181: %IOSXE-7-PLATFORM: 1 process wcm: 2418.1d5b.c584 Posture or Central Web Auth client, start session on IOS after client moves to RUN state
May 25 11:01:54.181: %IOSXE-7-PLATFORM: 1 process wcm: 2418.1d5b.c584 10.157.203.78 WEBAUTH_REQD (8) pemAdvanceState2 4414, Adding TMP rule
May 25 11:01:54.182: %IOSXE-7-PLATFORM: 1 process wcm: 2418.1d5b.c584 10.157.203.78 WEBAUTH_REQD (8) Replacing Fast Path rule^M on AP 20bb.c05b.6cd0 , slot 1 802.1P = 0^M
May 25 11:01:54.182: %IOSXE-7-PLATFORM: 1 process wcm: 2418.1d5b.c584 10.157.203.78 WEBAUTH_REQD (8) Successfully plumbed mobile rule
May 25 11:01:54.182: %IOSXE-7-PLATFORM: 1 process wcm: 2418.1d5b.c584 Plumbing web-auth redirect rule due to user logout

This part is weird, there is no logout anywhere, the client is still connected the whole time, unless there is somehow a reject or logout from the ISE being generated, but that should be in the logs

Again, many thanks for taking the time to view this

[ajc]

Not sure about the last line of your recent post but as soon as you reach the RUN state that means:

Client Fully Connected that has completed all required policy states.

I would be more concern if the messages were like: Sent Disassociate to mobile, Sent Deauthenticate to mobile, Cleaning up state for STA, etc.