Jump to content
Welcome to our new Citrix community!

Citrix ADC, Load Balance Storefront, Persistence and Citrix Workspace Favorites


Recommended Posts

Ok, this is a problem that makes no sense so here goes:

 

When I set up Storefront Load Balancing on Citrix VPX ADC 13.x, and set Persistence on the Load Balancing configuration to COOKIEINSERT, users can configure Favorites on their Citrix Workspace client.

 

However, when Persistence on the Load Balancing configuration is set to SOURCEIP, user are unable to configure Favorites on their Citrix Workspace client and instead receive the error message:

 

"Cannot complete your request."

 

Can someone please explain what magic is occuring?

 

Regards,

 

Ian 

Link to comment
Share on other sites

1) when you configure persistence, you are doing this on the storefront load balancer only and NOT the xml load balancing (if set).  And what persistence timeout is being used.

2) is the issue affecting internal users, external users (via gateway), or both?

3) is the system handling gateway ALSO load balancing storefront or not?

 

My guess is that you have users coming through a proxy between the users and the storefront load balancer either because the gateway is separate from the storefront load balancer OR other internet proxy in use.  So the source ip is being affected by all users looking like 1 IP address.  So cookie insert is working per client; but the source ip is not.

You might need to insert a client ip header at the proxy and then get lb to extract...or something else is going on.

 

But additional info:

When storefront processes the request, what xml broker do you point to:  does storefront point to the controllers directly and alternate itself or does it also point a load balanced config of the xml brokers. 

 

Otherwise a network trace AND viewing gateway syslog (if part of connection flow) AND storefront event lgos/controler broker service event logs may be needed.

 

 

 

 

 

 

 

 

 

Link to comment
Share on other sites

Rhonda,

 

Firstly thanks for your reply. First a summary of our setup:

 

1) All our users are external and access Citrix VIA Netscaler.
2) The Netscaler sits in a DMZ but has interfaces connecting to the customer LAN (contains customer apps) and to the shared resource LAN (contains domain controllers, Shared exchange server and Citrix Delivery Controllers). I KNOW this is bad design but it was a rush install and my knowledge of netscaler at the time was very limited.
3) Inbound traffic to the Netscaler from the internet is NAT'ed by our firewall (Netscaler Public IP<->Netscaler Private IP) so the netscaler never actually sees the incoming public IP address of the client only the NAT'ed private IP address.
4) Storefront servers sit in the same DMZ as Netscaler and share the same private IP address.

 

Now, to answer your questions:

1) Persistence is configured on the Netscaler under Load Balance -> Virtual Server and timeout is 60 minutes.
2) Issue only affects external users. When I test the configuration on the LAN, it works fine.
3) The Netscaler is load balancing the storefront servers.

4) I believe Storefront Servers point to our Delivery Controllers as XML brokers.

 

Is there much difference between COOKIEINSERT vs SOURCEIP? If not then perhaps I'll just keep COOKIEINSERT.

 

Regards,


Ian

Link to comment
Share on other sites

Well the thing is that since you are nat'ing the traffic all clients are coming from a single ip as the NAT IP. so sourceip persistence can't distinguish one user device from another;  they all look the same and follow the same persistence, whereas cookieinsert is still set by client device. Which is fine, as long as you aren't dealing with mobile or scenarios where cookie insert can't be set.  

 

As long as your storefront lb vserver is NOT publically accessible (without a gateway/hdx proxy involved).

Then nat'ing before the lb is not a problem...but you can could get hte firewall doing the NAT to do a client ip header insertion and then you could get the ADC to load balance based on the client ip extracted from this header (token load balancing and then identify header using http.req.header("<headername>")  typically used with an x-forwarded-for header.

 

So to recap:

1) Either cookieinsert or sourceip persistence can be used. However, for cookieinsert, any user device that can't set a cookie would have a problem. (And set global http parameter to cookie version 1 for best results).  For Source IP persistence, the L3 <source ip> in the packet needs to be distinct for each users. Usually this works great, but won't in your NAT scenario.  so 3) your alternate option would be to get the firewall doing the NAT'ing to insert a client-ip insertion header and then use token load balancing. Otherwise, cookieinsert is your best option.

 

2) StoreFront load balancing is straightforward. BUT you do want to make sure the storefront is BEHIND the gateway in HDX proxy mode and not directly accessible a public lb vserver.  Normally, your SToreFront servers would be in the internal network and only the netScalers doing gateway would be in the DMZ. You can do it the other way, you just have to make sure storefront is not accessible directly.   

 

Typical config doesn't usually require nat'ing:

- Gateway vpn vserver (VIP) is a public facing IP

- Netscaler NSIP and SNIP would be backend facing.

- the Storefront LB VIP would be backend facing.  And the existing NS SubnetIP used by the gateway could also be used for NS to storefront communication.

 

The NAT config you are using may cause you to do some unexpected configs that deviate from the typical. Not necessarily wrong if it works; but an added level of troubleshooting and attention needed to understand the communication flow.  But this does explain your LB behavior; so you can focus on that part first.

 

 

 

 

  • Like 1
Link to comment
Share on other sites

Rhonda,

 

Thanks very much for your help. I now have a much better understanding of how persistence works. Given that our clients also sit behind their own a NAT'd firewall it makes sense to just use COOKIEINSERT for persistence.

 

Just out of curisosity, should the timeout value be set to 0 or left at the default value of 2?

 

Regards,

 

 

Ian

Link to comment
Share on other sites

Persistence timeout (whether cookie or other) is an idle timeout. Its the timing for how long to remember the load balancing decision.

So the dependency is based on the app.

You want to keep a given user on the same storefront (backend) that they logged on to and avoid switching them to a new service until storefront itself is ready for a "new" transaction like a fresh login.  So, typically the persistence is dependent on the storefront idle time at which point the login prompt is reset. Default is 20 minutes; but you would have to check your store.

For CookieInsert, any value 2-1440 is number of minutes for a persistent cookie to be valid. Each new request resets the clock of the persistence decision, extending the cookie.  If a user does not interact with the site and the cookie expires, then the user will get a new load balancing decision on next request (and be prompted for a new storefront login).

If the CookieInsert is set to 0, then the persistence is tracked in a session cookie without expiration. Cookie is good until browser session is closed.

 

For Storefront load balancing, generally match the persistence timeout (Regardless of method) to your storefront idle timeout for logins.

 

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...