Jump to content
Welcome to our new Citrix community!

Missing RULE-based Persistence After 13.0 82.45 Upgrade

Josh Hester

Recommended Posts

Hi, folks!


So I just last night upgraded my remaining VPX instances (all running as virtual instances on older SDX 11520's) to 13.0 82.45.  ADM did the work, and aside from a couple of flukey hiccups, everything went OK.


This morning I got reports of some Duo authentication failing.  We use Duo for 2FA in our organization, and there are RADIUS LB virtual servers on one of these newly upgraded instances that proxies those RADIUS requests back to the Duo Auth proxies on UDP 1812 and 18120.


Upon review, it appears that none of my RADIUS virtual services, Duo or otherwise, that used RULE-based persistence have persistence set on them anymore.  My only other app that uses this is Cisco ISE, for which there's a RULE that triggers on RADIUS.ATTRIB(31) to keep clients connected to the same PSN that started their session -- those persistence rules are all missing now, as well.


As far as I can tell, none of my other persistence configurations are missing.  We have tons of COOKIEINSERT etc. on HTTP, and all those appears to be OK.


As a sanity check, I went back to an ADM backup of this same instance from 2 days ago and found the line in the config:

add lb vserver lb_vsrv_nsauthvpx_duo_radAuth18120 RADIUS X.X.X.X 18120 -timeout 6 -lbMethod LRTM -rule CLIENT.UDP.RADIUS.USERNAME -cltTimeout 30 -newServiceRequest 7 PERCENT -newServiceRequestIncrementInterval 6 -devno 53739520

This seemed odd to me -- notice that in the old config, there is no '-persistenceType RULE' entry, only the '-rule' line that I'd expect to go along with it. 


If I look at that same line in the saved config now, it looks like this:

add lb vserver lb_vsrv_nsauthvpx_duo_radAuth18120 RADIUS X.X.X.X 18120 -persistenceType NONE -lbMethod LRTM -cltTimeout 30 -newServiceRequest 7 PERCENT -newServiceRequestIncrementInterval 6 -devno 53739520

To play with this, I went to a RADIUS service on a lab instance I have and configured it as the production service should have been.  Here's what that final line of config looks like:

add lb vserver lb_vsrv_duo_radAuth RADIUS 0 -persistenceType RULE -timeout 6 -lbMethod LRTM -rule CLIENT.UDP.RADIUS.USERNAME -cltTimeout 120

To make sure there isn't some parameter position weirdness going on, I checked the output on a known-good working HTTP services that also used the same LB method but updated to use RULE based persistence -- its output matches the above entry.  So, it seems normal that '-persistenceType RULE .. <other stuff> -rule <ruleExpression>' is normal.  What seems abnormal is the absence of the '-persistenceType' in the original config, and my gut tells me this is why the setting didn't carry over post-upgrade.


As far as I can tell on my lab instance, I can add the  RULE persistence settings using the correct expression without any issues, so it's not like 13.0 82.45 deprecated that expression or something.  It definitely just seems like, for some reason, the pre-upgrade config (which was running on 13.0 71.44, for what that's worth) didn't actually have the '-persistenceType' flag defined, which means the upgrade process just treated it as '-persistenceType NONE'? ?

Link to comment
Share on other sites

What might be happening is that the legacy form of the advanced expression is client.udp.radius.username  (back before we had radius as a top level object in the expression syntax) and then we have radius.req.username (I think as I don't have an interface in front of me).

But we can parse radius and dns, just like http as radius.req.<stuff>/radius.res.<stuff> and dns.req.<stuff>/dns.res.<stuff>


While in the past both the legacy form client.[udp|radius].<stuff> and the new formats (noted above) have been supported. 

Its my guess that this "old" version of the advanced expressions deprecated too.  And so after upgrade the old persistence was no longer a valid rule and failed to migrate.

Or it should have migrated and you found a bug on this specific format variation.


If you are your prior build (assuming 13.0), you might have been able to run that expression through nspepi conversion tool and it might have shown this one as a conversion requirement.

Or it was just missed.


If you have the new 13.1 gui up, you can see if the policy evaluator can generate the old and new style expression or just the NEW expression format only.


Sorry, I don't have an adc handy to confirm any of my guesses. 

>> If it won't except either format, I would log a bug.

>> If it excepts the old format after you manually reconfigure it, then it might be an upgrade conversion bug and it might need to be logged.

>> If the old format isn't supported, but the new format is then the old format was deprecated (but whether it was documented or not is a different question) Or if the conversion tool didn't "flag" this, then it might be worth reporting to see if it is a bug in the conversion tool and we need to tell more people OR if it is as designed and we just didn't "confirm" this first.


I might have time to look later and let you know what I see (if someone can't confirm first).



I saw you mentioned 13.0.82.x and not 13.1 (possible similar reason; i just assumed 13.1 was involved)





Edited by Rhonda Rowland
Added note
Link to comment
Share on other sites

  • 3 months later...

We had a similar issue where the working persistence rule simply disappeared after a reboot. Support wrote:

This issue is a known bug, could you try to recreate the config using the GUI? 
In the CLI, the correct syntax needs to be: 
set lb group RADIUS-Calling-Station-ID -persistenceType RULE -timeout 120 -rule "\"CLIENT.UDP.RADIUS.ATTR_TYPE(31)\"".

In these updates, you need to add the "\" in the command. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...