06-20-2023 11:39 AM
Hello guys,
We have a distributed ISE deployment, 2 PAN nodes, 2 MnT nodes and 3 Policy Service nodes. We also have a Guest-self-registered portal. Please note, there is no type of node groups for the PSNs.
While logging in to the Guest Wireless, I noticed that if I point my services to the APAC PSN, the guest portal throws a 400 error and we can't get on it. When I mark the EMEA PSN as primary, we are ok to start using the portal. When doing an nslookup to the guest portal URL, it comes back with the EMEA PSN IP address as a result of the lookup.
Therefore, we can't serve the guest portal out of APAC - I'm guessing this is because there are no node groups and the Guest Portal is attached to a singular IP address? But I thought that once configured all PSN nodes should be able to serve the guest portal. Is this the case? am I wrong? can somebody please offer any feedback as to how accomplish this please?
Solved! Go to Solution.
06-22-2023 06:01 AM - edited 06-22-2023 06:03 AM
You're welcome. Yes that's right. My personal preference to fix that is just to create a single authorization profile and a single authorization rule for the redirection, and then creating the "ip host" aliases. That will allow any PSN that will start serving the session to be the owner of that session without any risk of redirecting the session traffic to a different PSN. Obviously those FQDNs that you will define in the "ip host" aliases need to be added to your public DNS records (unless your guests will be using your internal DNS servers), they don't have to be defined with any public IP, you can create them with the same IP addresses of the PSN interface that will be serving the guest portal.
06-20-2023 12:20 PM
I want to add: by looking at the authorization profile from the Policy Elements: I see that Web Redirection is marked, and using ACL "TEST_WEBAuth", but if I go look at the downloadable ACLs, there are no ACLs configured with the same name. This is how I usually do it, I checked but couldn't find the ACL anywhere else. Could this be part of the problem?
06-20-2023 08:31 PM
The same ACL name must be configured on your WLC. From ISE we push the ACL name. Check the entries in the ACL. It should allow access to APAC PSN as well on defined guest portal port.
06-21-2023 11:40 AM
I should mention this is for Meraki Wireless, not Cisco Wireless.
06-21-2023 09:54 AM
Downloadable ACLs are not the same as the redirect ACLs. Downloadable ACLs are used to enforce security based on the mateched rules. I think the issue you are experiencing would be caused by splitting the traffic across multiple PSNs. If that would be the case, you would get an error on the last PSN portal page. To fix this you can create multiple authorization profiles, each profile will be configured with each PSN FQDN for the redirection, and then you would need to create multiple authoriztion rule where you associate to each one the respective authorization profile. A simpler way to do this would be to create a single authorization profile without specifying the FQDN, and then on each PSN you add the command "ip host < the IP of the PSN > < the FQDN of the PSN >" from CLI. This will make sure that the session will always be served by the PSN that will start dealing with it.
06-21-2023 11:45 AM
Thank you for the explanation on the rules I was a bit confused.
So to have the 3 PSNs serve the web portal, I need to have an FQDN for each of them individually? I only have 1 authorization profile, with a FQDN assigned. When I changed the APAC PSN to be the primary for guest authorization, Guest Portal didn't work. So you're saying this is probably because I don't have an authorization profile pointing to the FQDN of my APAC node, and rather have 1 single FQDN defined under the AuthZ profile?
06-22-2023 06:01 AM - edited 06-22-2023 06:03 AM
You're welcome. Yes that's right. My personal preference to fix that is just to create a single authorization profile and a single authorization rule for the redirection, and then creating the "ip host" aliases. That will allow any PSN that will start serving the session to be the owner of that session without any risk of redirecting the session traffic to a different PSN. Obviously those FQDNs that you will define in the "ip host" aliases need to be added to your public DNS records (unless your guests will be using your internal DNS servers), they don't have to be defined with any public IP, you can create them with the same IP addresses of the PSN interface that will be serving the guest portal.
06-22-2023 08:23 AM
thank you Aref! I think this will be my solution, thanks a lot for the help!
02-20-2025 02:53 PM
Hello,
I would like to validate if the following setup is possible.
- To have a Guest SSID with Cisco ISE guest portal Self Registered with Sponsor approval without the need to guest insert credentials.
I would like to have the following flow:
I know if the guest is in "waiting menu" and sponsor approves the guest is automatically authorized.
But if for some reason the guest leave this page or the sponsor approves only after 30min, the automatic approves does not work.
Another scenario, that I would like to validate is, how can I ensure that Guest user do not require to insert the credentials in the next days? in WLC I can only configured the session timeout for maximum of 1 day. I saw some documentation regarding the feature "remember me" that basically checks the MAC address inside the Guest endpoints group.
Is there another way to ensure that guest user will never need to insert the credentials after the sponsor approval during 7 days?
02-24-2025 02:02 AM
Why would you want the registration portal if you don't want the guest users to type in their credentials? why don't you just use the hotspot portal?
You can't rely on the automatic login feature to allow users to be authorized without typing their credentials, because as you said if the user moves away from the landing page that feature won't work anymore.
The place where you define the retention of the guest users is in the Guest Type section where you can custom the settings on the default ones, or you can create your own custom type. Then in the portal form settings you associate the type you want. That way the users won't need to type in their credentials for the duration of their retention.
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