- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Cisco ISE Captive Portal
I've got a strange issue going on and not sure what could be the cause.
I'm setting up a Wireless Guest SSID using Identity PSK with Radius and Cisco ISE as my Splash Page. If I use the private IP addresses of my ISE servers in the Radius Server fields, everything works fine and I get my redirect url from ISE for the Captive Portal page, the page loads and I'm able to accept.
However, if I try to use the FQDN of my ISE servers in the Radius Server fields, I get redirected to my Captive Portal page, but the page does not load, and instead I get an ERR_ADDRESS_UNREACHABLE.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi ,
That probably means that the AP wasn't able to resolve your Cisco ISE FQDN. Double check the DNS configuration of the AP and take a packet capture on the LAN and watch for the DNS queries.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
At first this is what I thought. But traceroutes and pings to fqdn from the AP resolve and servers are reachable. And the radius flow is actually working, I see my device going through my Guest Portal Sequence in ISE. It's when I get redirected to ISE's splash page that I get the error message and the page won't load.
Redirect coming from ISE for splash page is formatted as 'https://<privateip>:8443/.....' I've also tried substituting the privateip with the fqdn, but I get same results.
However, if I use private ip of ISE as radius server instead of fqdn, ISE's splash page 'https://<privateip>:8443/.....' loads just fine. I just don't understand why using private ip vs fqdn in the radius server field would have any effect on the splash page loading.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Isn't it your client that needs to resolve the ISE FQDN.
In case of a webauth situation you are already layer 2 authenticated and can communicate layer 3 but your requests get redirected.
In case of Meraki AP's you need to make sure your ISE FQDN's are added to the walled garden so the requests don't get redirected.
I hope this helps.
