The Citrix NetScaler is a great load balancer with numerous options when it comes to the backend loadbalancing method and persistence settings. Here are the available persistence settings based on the type of vServer:
| Persistence Type | HTTP | HTTPS | TCP | UDP/IP | SSL_Bridge |
|---|---|---|---|---|---|
| Source IP | YES | YES | YES | YES | YES |
| CookieInsert | YES | YES | NO | NO | NO |
| SSL Session ID | NO | YES | NO | NO | YES |
| URL Passive | YES | YES | NO | NO | NO |
| Custom Server ID | YES | YES | NO | NO | NO |
| Rule | YES | YES | NO | NO | NO |
| SRCIPDESTIP | N/A | N/A | YES | YES | N/A |
| DESTIP | N/A | N/A | YES | YES | N/A |
When a new vServer is created and service are bound to it, a persistence method must be selected – there is no default value set. Some network topologies or access methods may rule out certain persistence types – for example, if traffic is coming through a proxy, the NetScaler may see a translated IP address. This would cause SourceIP to appear as if it were not working.
The problem with CookieInsert
CookieInsert is a preferred method as it does not suffer from the above network scenario and it does not introduce any (considerable) load on the NetScaler – but don’t be fooled, as this persistence type is not without issue. Some web services and applications simply do not support CookieInsert. Then there’s the more important issue: CookieInsert may inadvertently expose details about your internal resources. This is only an ‘issue’ when the vServer is a publicly facing vServer and the internal servers contain sensitive data.
This is surely not the case when the vServer in question is an SSL vServer – all communication is encrypted right?
Yes, but what if the client isn’t even authenticating or trying to gain access to encrypted data. When you use CookieInsert, the NetScaler sends a cookie to the client that is in the following format:
<NSC_XXXX>= <ServiceIP> <ServicePort>
where:
- <NSC_XXXX> is the virtual server ID that is derived from the virtual server name.
- <ServiceIP> is the hexadecimal value of the IP address of the service.
- <ServicePort> is the hexadecimal value of the port of the service.
Edit 12/16/15: As of NS 10.5 build 55.8 and later, the persistence cookie can by encrypted with a passphrase by using the following command:
set lb parameter -useSecuredPersistenceCookie ENABLED -cookiePassphrase <passphraseHere>
More details here: http://docs.citrix.com/en-us/netscaler/11/traffic-management/load-balancing/load-balancing-persistence/http-cookie-persistence.html
So when you connect to an SSL vServer that is using CookieInsert, you will get a persistence cookie from the NetScaler that looks like this:
The string in question is this:
NSC_wTfsw-SVUSEH-TTM=ffffffff09091f0845525d5f4f58455e445a4a42378b
Seems like useless garbled characters, right? Not so much. It’s a fairly simple cipher – see this post here for more details: http://itgeekchronicles.co.uk/2012/01/03/netscaler-making-sense-of-the-cookie-part-1/
Using the provided python script, my decrypted cookie gives you a bit of detail about where it came from:
vServer Name=vServ-RUTRDG-SSL
vServer IP=10.1.1.25
vServer Port=443
While maybe not the biggest deal for some environments – this can show up in penetration testing or audits on external resources.
** When the passphrase is added, the decrypt invalidates the IP address and port but not the hostname:
vServer Name=vServ-RUTRDG-SSL
vServer IP=188.112.230.179
vServer Port=26792
Choosing the right persistence type
External resources will likely want to choose something other than cookieInsert for persistence to avoid exposing information about the backend servers. In the case of a public SSL vServer, the persistence method should be set to SSLSession as this type uses the client SSL session ID to persist and does not suffer from issues caused by network topology or proxying.
For non-SSL resources, more consideration may be needed as SourceIP may not be an option. Some web services may be able to get away with no persistence set – while it is required for the majority. It may seem illogical but another option is to set persistence to none and use the loadbalancing method of SrcIPSrcPortHash. This will get around the network\proxy issue by taking a hash of the source IP and source port thus preventing the client from getting a different backend server.
(Source: http://support.citrix.com/article/CTX119941/)
Don’t have a NetScaler in your environment? Download a trial today!