Radius Persistence with Load Balanced ISE

[Damien Miller]

I wanted to discuss an issue I found out in the field regarding load balancing radius for ISE.  Specifically around the persistence and where I think the published configuration could be amended to help others.  I only have Citrix Netscalers at my disposal right now, so my tests are limited to that platform.  It looks like the F5 guide is much more thorough and covers this issue with attribute fallback. 

If we reference the published load balancing guides for Netscalers, ACE, or BRKSEC-3699, the suggested persistence config is using AVP 31 - calling station ID. 

https://community.cisco.com/t5/security-documents/citrix-netscaler-1000v-load-balancing-config-for-ise/ta-p/3634374

ex. add lb vserver radius-auth RADIUS 172.16.0.16 1812 -rule "CLIENT.UDP.RADIUS.ATTR_TYPE(31)" -cltTimeout 120

This works fine for radius client authentications since client authentications typically include radius attribute 31.  The breakdown appears when you start leveraging TrustSec features and the NADs are trying to provision a cts pac.  The pac provisioning process uses radius but does not include radius attribute 31.  Persistence fails because AVP 31 is not found in any of the pac provisioning packets and thus you get very inconsistent results.  Eventually a switch running 16.6.4 will provision a pac but the stars have to align just right for the magic to happen.   The F5 config guide discusses and solves this with the irule using calling station id if available then falling back to NAS IP. 

Testing has indicated a simple way to address this with Citrix LBs.  By changing the persistence to compound both attribute 4 (NAS IP) and attribute 31 (calling station ID), the pac provisioning requests persist properly.  Load balancing for client auth still occurs in a fashion that spreads load out evenly, and it presents no issues with pac requests missing AVP 31. 

The ammended config looks like -rule "CLIENT.UDP.RADIUS.ATTR_TYPE(31)+CLIENT.UDP.RADIUS.ATTR_TYPE(4)"

With TrustSec gaining more widespread support I'm hoping the help others avoid the same issue if they go to the Netscaler guide/breakout presentation without also reading the F5 guide.  

[Arne Bier · Accepted solution]

Thanks for sharing.  These types of experiences probably expand your understanding of load balancers and such.  I have a good deal of respect for anyone who can configure a load balancer properly - to me it's just a black box.  Once you start messing around with F5 iRules you turn into a part time developer and looking through reams of debugs to figure out what's going on. 

[Damien Miller]

I find load balancers are really good at two things....1. load balancing, and 2. forcing you to learn way more than you might want to know about certain protocols. They sure are nice once they are in and all set up though.

[Nick Ciesinski]

I think you could mimic the same logic of the F5 iRule (if exists / else) by using ALT vs joining them together (+). 

-rule "CLIENT.UDP.RADIUS.ATTR_TYPE(31) ALT CLIENT.UDP.RADIUS.ATTR_TYPE(4)"