cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1227
Views
0
Helpful
7
Replies

Cisco ISE Guest Portal

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? 

1 Accepted Solution

Accepted Solutions

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.

View solution in original post

7 Replies 7

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? 

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.

I should mention this is for Meraki Wireless, not Cisco Wireless. 

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.

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? 

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.

thank you Aref! I think this will be my solution, thanks a lot for the help!