05-14-2019 02:31 PM
Hello all,
I wanted to pose this question to the community to see what kind of feedback I'd get. I understand that the recommended solution for multiple PSNs is to place them behind a load balancer. However, are there any downsides or potential problems I could run into by doing so? Things I have in mind are advance features such as using SGTs, pxGrid, and any other feature that is known to be an issue when used behind a load balancer. I'm asking specifically for version 2.3 or later.
Your feedback is greatly appreciated!
Terence
Solved! Go to Solution.
05-14-2019 03:29 PM
05-15-2019 02:31 PM
The result of a non static FQDN, the URL is https://ip:port/... so the client device will see https://ise-box-01.internal.org:8443?fhfhkshfs etc - at that point you're snookered because the cert that ISE presents to the user will not contain .internal.org (or at least, no public CA will make a cert for you using that private domain). This is why you need to perform the "translation" of internal domain to public domain using the static override in the AuthZ.
I hope that makes sense :)
05-14-2019 03:29 PM
05-14-2019 07:10 PM
Ditto to what @Damien Miller already pointed out. Nothing will prepare you for this as much as the fun and joy of a real world deployment. But there is a lot of collateral that you can read (e.g. if you're doing F5 then Cisco has plenty of great stuff to read up on).
I would add another small curveball. The load balancer can also perform SSL offload and I ran into one case where the ISE Guest Portal certs were replaced because they had expired, yet, the end user still got the old expired cert (browser warning). it took a while to realise that the F5 was still presenting the old cert! So it had to be updated there too. Watch out for that if you're doing SSL Bridging (I think that's what they call it).
Other crazy topics are things like GTM (Global Traffic Manager) which is like a DNS server on steroids. Can be a great help for Guest Portals again to allow the F5 to load balance across multiple data centres and figure out which PSN to maintain persistence to (because guest.mycompany.com must resolve to SOMETHING - that something has to be deterministic - if you're load balancing across data centres (i.e. two VIPs essentially) then you have to steer the end user to the correct VIP.
It helps having a load balancer SME on board when doing complex jobs.
05-15-2019 06:02 AM
Thank you Arne and @Damien Miller. This information really helps in considering whether to put our PSNs behind our NetScaler. Even though we're using a distributed deployment, our environment is relatively small compared to other organizations within the healthcare industry. So I'm trying to decide if putting them behind a load balancer will make sense for us and doing the extra work to move them since our LB is in our DMZ. That means opening ports in the firewall and so forth. At this point, it's the HA/failover and using a single static FQDN for both PSNs for the guest hotspot URL redirect that would make sense for this.
Based on a conversation I had with TAC, they said as long as both PSNs stayed up, I could use a single static FQDN for hotspot portal by creating two A records with the same name pointing to each PSN IP. The first PSN on my NADs will authenticate clients and if that goes down, then the next will be used to authenticate for the same FQDN. The issue with this is that if a client authenticates to the hotspot portal and then that PSN goes down, that session ID is tied to it and the new PSN will have no knowledge of it to keep the guest process going. Therefore, the client will need to terminate (either manually or an ISE admin deleting the endpoint) and start over. This is, obviously, not a good user experience if this scenario was to play out.
At this point, it's either allow ISE to dynamically resolve the PSN via the PTR and not use static FQDN or place them behind a load balancer. Thanks for your feedback on this question. But I do want to ask one more as it relates to the dynamic resolution for the URL redirect.
When not using static FQDN, the URL is https://ip:port/... and will resolve to the IP of the PSN authenticating the client. Question: If my PSNs are in part of our internal domain (internal.org) but I want to use them in our public domain (public.org) and I have a zone for each domain on our DNS servers, is there a way to resolve the public resource records for the PSNs instead of the private? In other words, no static FQDN defined in the AuthZ profile so when a client authenticates, DNS will return the public record rather than the internal.
05-15-2019 06:59 AM
@Arne Bier and @Damien Miller,
I was just thinking about my last question from my previous post. My guess is that I would have to reconfigure both PSNs to be part of the public domain instead of the private domain (ip domain-name private.org) and then likely replace my certs, correct?
05-15-2019 02:37 PM
I just saw your reply to your own question. Yip - you're right. You can unconfigure an ISE node with the
"application reset-config"
command and then you have the chance to set the hostname etc. it's effectively a complete rebuild of the ISE node. If it's patched then you retain that - but config is blown out of the water.
05-15-2019 02:31 PM
The result of a non static FQDN, the URL is https://ip:port/... so the client device will see https://ise-box-01.internal.org:8443?fhfhkshfs etc - at that point you're snookered because the cert that ISE presents to the user will not contain .internal.org (or at least, no public CA will make a cert for you using that private domain). This is why you need to perform the "translation" of internal domain to public domain using the static override in the AuthZ.
I hope that makes sense :)
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: