WLAN Captive Portal Redirection Issue

[mrinkognito76]

I am having an issue where, after entering the WLAN password, I am not being redirected to the captive portal.

Could you please let me know what settings I need to adjust in the ISE?

[David00]

Hey @mrinkognito76, can you share more information about your environment? What network hardware are you using? If Catalyst wireless, are your APs in flex connect or local mode?

[mrinkognito76]

I am using a Cisco Catalyst 9800-CL wireless LAN controller running version 17.15.2. The access point model used is AIR-AP2802I-E-K9, and it is currently operating in local mode, not FlexConnect.

Regarding the authentication flow: When a client tries to connect, the request is successfully authenticated by Cisco ISE. The controller then establishes the wireless session.

[David00]

Did you set the AV pairs for url-redirect-acl and url-redirect as shown in the Authorization Profile example section?
https://community.cisco.com/t5/security-knowledge-base/ipsk-identity-pre-shared-key-manager-portal-server-for-ise/ta-p/3904265#toc-hId-919452033

This document also details the rest of the setup that ISE needs, which you can either use the ERS API integration to configure automatically, or manually setup the authorization profile in ISE.

I'd also recommend looking at the logs of your WLC and running a client debug (see Radioactive Trace in the WLC's Troubleshooting section), and running the result of the debug through Cisco's WLC Debug Analyzer.

[mrinkognito76]

I have created this via the API and it is exactly as described in the instructions on the WLC there is already an active session but it says web auth pending I also noticed when I open the website with the url the WLC always makes several redirects

[David00]

You'll have to look at the client debug logs, then. My guess is that you haven't assigned a VLAN to the ISE Authorization Profile, or, the VLAN you've assigned doesn't exist on the WLC, or, you haven't enabled AAA override on the wireless profile policy.

[ciesinsn]

Are you able to access the URL WLC is trying to redirect to manually from a device not connected to that SSID? If you can then its a setting missing from the ISE / WLC config.

I am having an issue where, after entering the WLAN password, I am not being redirected to the captive portal.

The WLAN password comment has me wondering, are you using a iPSK Manager WLAN password (psk) and expecting a portal redirect or does your onboarding portal have its own password everyone would use?

[mrinkognito76]

Even if I am not connected to the SSID, I can still access the website. I also have the following in the authorization profile in the ISE and the following in the policy set in the ISE

Authorization Profil
Access Type = ACCESS_ACCEPT
cisco-av-pair = url-redirect=https://myurl.de:443/index.php?portalId=3e6433fb-d363-4850-a6a1-7120f8ee097d&sessionId=SessionIdValue&client_mac=ClientMacValue
cisco-av-pair = url-redirect-acl=ACL_IPSK_REDIRECT

[mrinkognito76]

This one is my Wlan profile

wlan WP_HHG-Guest 32 IPSKSSID
mac-filtering Authz_LIST_iPSK
peer-blocking allow-private-group
radio policy dot11 24ghz
radio policy dot11 5ghz
no security ft adaptive
security wpa psk set-key ascii 8 [my password]
no security wpa akm dot1x
security wpa akm psk
no shutdown

[David00]

I noticed that if you have an incorrect SSL cert, some clients won't even load the captive portal login. Do you have an SSL cert (even self-signed should be fine) for your https://myurl.de?

[David00]

Hmm actually after further testing, I am also seeing weird behavior when working with different sub domains.

Maybe @ciesinsn can chime into this one because I think I am reproducing the same issue that @mrinkognito76 has raised.

NVM - figured it out. See next comment.

In my iPSK Manager, I have three different portal hostnames (aka, subdomains)

When I create a captive portal against subdomain1 and port 8443, everything is fine.
If I create a new portal for subdomain2 and port 8443, clients detect the need for the captive portal, but they don't ever load the captive portal page.

Both subdomains resolve to the same IP (even when waiting for the captive portal to load, I can resolve DNS).
My 8443-ssl.conf file for Apache is setup with a wildcard cert, and I confirmed that clients are seeing the cert when pulling up either portal at subdomain1 (via automatic captive redirect) or subdomain2 (via manual navigation directly to the URL, since it's not loading automatically with the captive redirect).

I'll keep digging tomorrow but wanted to share my findings here.

[mrinkognito76]

I do not have a self-signed certificate for my URL, it is a certificate issued by a CA

[mrinkognito76]

I have also set it so that my portals listen on 443 and my admin portal on 8443

[David00]

I figured out my issue - I forgot that I had a URL filter configured on my flex profile (my setup is with Flex Connect APs), and I was allowing my subdomain1.captiveportalexample.com but not subdomain2.captiveportalexample.com.

One thing that helped me figure out my issue was looking at the client details "Security" tab on the WLC, while the client is connected and in the authorization state. This should show you the ACL applied to the client, the redirect URL, the VLAN, etc. Also, from the client side, you can try to run DNS queries to resolve the URL manually.

[ciesinsn]

I converted this to a discussion as I don't believe this is a actual issue with iPSK Manager and just didn't want to close the issue out if there was additional comments to help figure out the configuration issue.