ISE RADIUS persistence on Citrix Netscaler query

[andrewswanson]

Hi

I'm running into some teething issues with Cisco ISE RADIUS persistency on a Citrix MPX Netscaler.

Configuration is pretty much in line with Cisco document below.

https://community.cisco.com/t5/security-knowledge-base/citrix-netscaler-cli-configuration-for-cisco-ise-radius-and/ta-p/4679861

I'm using a Citrix persistency group to share persistence sessions between the RADIUS 1812 and 1813 virtual servers. This is rule based i.e. use RADIUS attribute 31 (calling-station-id) with a backup of SOURCEIP:

add lb group ISE-PERSISTENCY -persistenceType RULE -persistenceBackup SOURCEIP -backupPersistenceTimeout 120 -timeout 120 -rule "CLIENT.UDP.RADIUS.ATTR_TYPE(31)"

This is working fine for most NADs (Cat 3650) but seems to break for some when they attempt to refresh CTS environment data (username "*CTSREQUESTS*") or refresh CTS pac (username "CTS client"). In both cases, these requests don't have a RADIUS attribute 31 so should use SOURCEIP for persistence. I can view persistence session on the Netscaler for the rule, but there are none listed for SOURCEIP.

I have a support call open with Citrix to confirm whether there is an issue with Citrix Persistency Groups that are rule based with a backup persistence of SOURCEIP.

In the meantime I'm considering looking at "Content Switching" on the Netscaler for ISE. In this setup

• The Content Switching vserver checks if the RADIUS request has a calling-station-id attribute RADIUS.REQ.CALLING_STATION_ID.EXISTS
• If so, the request is sent to a virtual server configured with rule based persistence (matching on calling-station-id)
• If not, the request is sent to a virtual server configured with SOURCEIP persistence

Just looking for feedback if this is a good idea if it turns out there is an issue with rule based persistency groups on the Netscaler.

Thanks
Andy

[Arne Bier]

Hi @andrewswanson 

I can't offer any advice on Netscaler (sorry) - but I was wondering if you're doing RADIUS load balancing only?  And if your devices are IOS-XE, then you don't need an external load balancer. IOS-XE has the built-in load balancing feature that works brilliantly.  But it's only for RADIUS (MAB and 802.1X).  TACACS cannot be load balanced - Cisco would have to develop that into the product. 

[andrewswanson]

Thanks for that Arne

Currently using Netcaler for RADIUS (MAB, 802.1x and CTS) as well as for ISE probes (snmp trap and dhcp). It works well (the recent CTS issues aside) and simplifies the NAD configuration.

I think that a Netscaler upgrade from 13.1 to 14.1 should help resolve my issue - 14.1 introduces support for a boolean "if" operator for rule based persistence.

I believe that the following would work for ISE RADIUS persistence with 14.1:

RADIUS.REQ.CALLING_STATION_ID.EXISTS.IF(CLIENT.UDP.RADIUS.ATTR_TYPE(31), CLIENT.UDP.RADIUS.ATTR_TYPE(4))

This should be evaluated as:

If RADIUS request contains calling-station-id
then
         use calling-station-id (attribute 31) for persistence
else
         use NAD source IP (attribute 4) for persistence

I'm due to upgrade the Netscalers soon so will post an update then.

Thanks
Andy

[andrewswanson]

I've done some more testing for CTS RADIUS persistence on a Citrix loadbalancer running 14.1 code. For this test I used:

• NAD: Cisco Catalyst 9k running 16.12.11 - switch has a management IP Address of 10.40.110.20
• 802.1x client: MAC Address bc:0f:f3:74:16:ec

For RADIUS persistence on the Netscaler I wanted to use:

• Calling-Station-ID (RADIUS attribute 31) for 802.1x sessions i.e bc:0f:f3:74:16:ec for this test
• Switch management IP for CTS requests (RADIUS attribute 4 or just the request packet's source IP address) i.e 10.40.110.20 for this test.

TEST 1
Using the persistence rule listed in Cisco documentation. This rule should use Calling-Station-ID for persistence. If that attribute isn't present, the source IP should be used.

When I generate both 802.1x and CTS requests on the switch, only persistence sessions for 802.1x (Calling-Station-ID) are created.

TEST 2
Citrix introduced an "if" rule operator in ver 14.1. I used this to create a rule that would use RADIUS Attribute 31 (Calling-Station-ID) for persistence. If that attribute wasn't present, then RADIUS Attribute 4 (NAS IP Address) would be used

When I generate both 802.1x and CTS requests on the switch, persistence sessions for both 802.1x and CTS sessions are created. Calling-Station-ID is shown correctly but the NAS IP Address isn't (should be 10.40.110.20)

TEST 3
I created a persistence rule that would append Calling-Station-ID AND the packet SOURCEIP together.

This worked as expected with the 802.1x session showing as "bc-0f-f3-74-16-ec10.40.110.20" and the CTS showing as "10.40.110.20" (as CTS requests don't contain a Calling-Station-ID attribute).

So it looks like using a backup persistence of SOURCEIP with a RULE doesn't work in either Citrix 13.1 or 14.1 as seen in TEST 1. TEST 2 looks promising but Citrix AppExpert can't seem to display RADIUS Attribute 4 properly. At least I've got something to approach Citrix support with.

Andy

[andrewswanson · Accepted solution]

Citrix support came back with a fix for this using the rule below:

CLIENT.UDP.RADIUS.ATTR_TYPE(31) ALT RADIUS.REQ.NAS_IP_ADDRESS.VALUE.TYPECAST_TEXT_T

With this rule, persistence uses string2 (NAS IP Address) if the evaluation of string1 (calling-station-id) results in an undef exception or the result is a null string.

Screenshot below shows 802.1x session using "bc-0f-f3-74-16-ec" (calling-station-id) for persistence and the CTS using "10.40.110.20" (NAS IP Address).

Will look at deploying this persistence group rule to the live RADIUS deployment.

Andy