cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
210
Views
5
Helpful
4
Replies

ISE Netscaler Loadbalancing Cross-Service Persistence

sebastianrei
Level 1
Level 1

Hi everyone,

I'm following this guide for my setup: https://community.cisco.com/t5/security-knowledge-base/citrix-netscaler-cli-configuration-for-cisco-ise-radius-and/ta-p/4679861#toc-hId-279038066

I also checked this discussion about radius persistence on Netscaler:
https://community.cisco.com/t5/network-access-control/ise-radius-persistence-on-citrix-netscaler-query/td-p/5223105

At the moment, radius load balancing is working fine. However, I'm trying to figure out how to get cross-service persistence between the guest portal (hosted on ISE for web auth in a dot1x wireless setup) and the corresponding radius session.

On F5 - from what i read -, there's an explicit option for cross-service persistence, which keeps web and radius traffic for a client pinned to the same backend ISE PSN. I'm not sure how to achieve the same behavior on Netscaler. I already use a persistency group - but that only works for radius, i cannot add my portal vserver.

From what I understand, the guest session context (for self-registration and portal state) only exists on the PSN where the user initially connects - it's not replicated across other PSNs. If the redirect or radius request later hits a different PSN, that node won't recognize the session, which can break the flow.

Can anyone confirm if that understanding is correct, and if there's a way to configure cross-service persistence on Netscaler so both the web and radius traffic from a client always hit the same PSN?

Thanks for any advice!

4 Replies 4

andrewswanson
Level 7
Level 7

Hi

For persistency groups, there is an option called "Use vServer Persistence". The NetScaler documentation states:

Use this parameter to enable vserver level persistence on group members. This allows member vservers to have their own persistence, but need to be compatible with other members persistence rules. When this setting is enabled persistence sessions created by any of the members can be shared by other member vservers.

I haven't used this myself but it does sound comparable with the F5 feature

hth
Andy

Thank you for the reply, I tested the “Use vServer Persistence” option, but I’ve hit a protocol mismatch issue. When I try to bind my guest portal vserver (which is tcp) to the same persistency group used for radius, I get: > bind lb group ise-lab guest-portal-ise-lab ERROR: Operation not permitted., because i use following expression: CLIENT.UDP.RADIUS.ATTR_TYPE(31) ALT RADIUS.REQ.NAS_IP_ADDRESS.VALUE.TYPECAST_TEXT_T. I am not sure how i can get that working for both tcp & radius/udp.

Hi The Netscaler link below specifically mentions how to do this for radius and http:

 

https://docs.netscaler.com/en-us/citrix-adc/current-release/load-balancing/load-balancing-persistence/sharing-persistent-sessions.html

Assume v1 and v2 are bound to a load balancing group, v1 is a RADIUS type virtual server and v2 is an HTTP type virtual server. ‘Radius.req.avp(8).value.typecast_text_t’ persistency is configured on v1 and ‘client.ip.src’ is configured on v2.

When traffic flows through the RADIUS virtual server v1, it creates a persistent entry based on the evaluated rule string. Later, when traffic reaches the HTTP type virtual server v2, v2 checks for the persistence entries on the load balancing group and uses the same persistence session to direct traffic to the same back-end server.

hth

Andy

The NetScaler article shows the vservers using the rules below

RADIUS vsever persistence: Radius.req.avp(8).value.typecast_text_t (Framed IP Address)
HTTP vserver persistence: client.ip.src

they share the same type of persistence attribute i.e. the client's source IP

Your RADIUS rule uses Calling-station-id with a back up of NAS IP Address. Calling-station-id is usually the mac address of the client (not its IP address - if these are wireless clients, I think that you can change the wlc to send the client's IP in the Calling-station-id. That way you could use

RADIUS vsever persistence: CLIENT.UDP.RADIUS.ATTR_TYPE(31) ALT RADIUS.REQ.NAS_IP_ADDRESS.VALUE.TYPECAST_TEXT_T
HTTP vserver persistence: client.ip.src

NetScaler could then use the client's IP Address for persistence in both of the vservers - I've not tried any of this (just thinking outside the box)

hth
Andy