Where can I find documentation or a guide for deploying ISE 2.3 behind any Load Balancer

[Terence Lockette]

Hello all,

I'm looking for a deployment guide for setting up ISE 2.3 behind a load balancer.  We use Citrix Netscaler for our load balancer and I can't seem to find any documentation for version 2.3.  The closest I was able to find is found here but for F5 and ISE 1.x according to Table 1 of the document.

https://community.cisco.com/t5/security-documents/how-to-cisco-amp-f5-deployment-guide-ise-load-balancing-using/ta-p/3631159#toc-hId--1739800870

We did find a past post for some guidelines but it doesn't provide any details pertaining to how we need to set things up on the ISE/NAD side found here:

https://community.cisco.com/t5/security-documents/ise-load-balancing/ta-p/3648759

Any assistance in where I can find updated documentation would be great.

Thanks.

[Damien Miller · Accepted solution]

I haven't seen specific documentation for the NAD side of load balanced ISE other than a blurb in the link you shared. The base radius configuration doesn't really change on the NAD, the piece that may change on the NAD is adding dynamic authors for the COA if they come from IPs other than the VIP.

Another helpful tip is to match your radius interim update interval to slightly less than your load balancer persistence value. If your LB team says they can only do 1 hour of persistence on the VIP, set "aaa accounting update newinfo periodic 55", or similar so that the NAD reports in to the same PSN before the persistence drops.

Those are the only two things that come to mind from the NAD side. The configuration of the LB is the same regardless of the version of ISE since radius hasn't changed, just the gui/screenshots.

I have one addition I have that is missing from the LB guide for Netscaler if on the persistence. If you are using TrustSec, you will want to compound the value.
https://community.cisco.com/t5/identity-services-engine-ise/radius-persistence-with-load-balanced-ise/td-p/3694180

[Terence Lockette]

Thank you, sir, for your helpful feedback. This helps in understanding what I need to do to a degree. One other question...if I already have my PSNs deployed and running on a particular VLAN/Subnet outside of the VLAN/Subnet that my LB's are on, do I need to move my PSNs to that subnet or can I just use L3 routing to a VIP on the LB and then point my NADs to the VIP for RADIUS and leave my dynamic COA as the actual IP of the PSNs?

[Damien Miller]

I was trying to think through how that would work, but I suspect you will run in to issues with the return communication for RADIUS. There is no issue receiving a COA from the PSN IP since you can define the list of dynamic authors, but return RADIUS traffic would be expected from the VIP IP. In all past deployments I have used source NAT to rewrite the IP source in the RADIUS traffic to the VIP IP so that the NADs think they are talking to the VIP.
You will want to move the PSN's to an internal LB subnet so you can use the SNIP as the PSN default gateway. This way you can also follow the L2 recommendation when having PSN's in a node group.

[Terence Lockette]

Agreed. Perhaps it would be best if I kept things as they are and use the loaf balancing feature on my switches.

Thanks for your insight and feedback on this.

[Terence Lockette]

Hello Damien (or anyone else in the forums),

Can anyone answer my question in response to Damien's regarding the placement of the PSNs or possibility of using L3 routing to a LB while keeping my PSNs in their current VLAN?

Thanks!

[Arne Bier]

I have not seen cases of L3 routing between PSN and the "inside network" of a load balancer.  Typically the PSN will have a default gateway set as the "inside" address of the Load Balancer to allow the non-SNAT'd traffic to return to its originator (that came in via the VIP).

If you need CoA then you cannot SNAT on the VIP, because this breaks ISE.  e.g. imagine you had 1000 switches that you wanted to manage as a single IP in ISE, then normally you would perform SNAT on the VIP.  ISE doesn't interpret the NAS-IP-Address attribute - it uses the IP Header's Source IP Address as the origin information.  This is why SNAT breaks the CoA operation because there is no way to singularly address any one of those 1000 switches any longer.

In the same example of 1000 switches, if you used ISE just for TACACS, then I would recommend SNAT on the VIP, because you don't use CoA in TACACS.  It would make the management in ISE very easy (one entry).  Of course you should extend that scenario to having two VIPs (for HA).  Then ISE has two entries :-) - still better than 1000 entries :)

[Terence Lockette]

Arne,
What about this scenario:

1. Keep ISE PSNs in current VLAN (no load balancer)
2. Use DNS round robin
3. Create 2 DNS entries for my guest hotspot portal with each entry pointing to the IP of each PSN (ie guestportal.domain.org)
4. Generate a CSR with the following:
* CN = guestportal.domain.org
* SAN = guestportal.domain.org, psn1.domain.org, and psn2.domain.org
5. Have public CA sign the cert
6. Install cert on both PSNs
7. Use static FQDN in ISE AuthZ profile for URL redirect to use guestportal.domain.org
In this scenario, if PSN1 is unreachable and we're using round robin DNS, can ISE then use PSN2 to keep traffic flowing for URL redirection?

[Arne Bier]

Hi @Terence Lockette 

Have a look at this posting I did a while back about implementing Guest Portals across two PSN's without a load balancer.  It's the sure way to make this work reliably.

https://community.cisco.com/t5/identity-services-engine-ise/guest-ha-design-with-two-psn-s-and-no-load-balancer/td-p/3503000

Not sure if relying on DNS alone will do the trick - you might run into "weird situations". Rather make it deterministic.

[Terence Lockette]

Arne,
Much appreciated, sir. I'll check it out and if all works well, I'll mark this as answer accepted.

[Damien Miller]

I screwed up my terminology earlier.  On Citrix it is RNAT, you rewrite the PSN IP as the VIP going back to the NAD.  

So 100% agree, I would avoid source NAT from NAD to ISE, have the Citrix/LB pass the original NAD source IP.