Skip to content
Oct 22 / The Architect

My top Netscaler feature requests – updated

I’ve worked with Netscaler, and Netscaler Gateway (formerly Access Gateway Enterprise Edition) for a number of years now, and whilst I’m a huge fan of the technology, over that time I’ve built up a number of “I wish it did this” items. Some are the results of things I’ve found, whilst others have been requested by end users.

I though it was time to put them down on paper (well, in electronic format at least), share with the world and get some feedback and hopefully visibility.

Update: 31/12/13 – the original title of this blog was “Top 5 feature requests” but I’ve added a couple more since.

In no particular order…

1. Allow an Access Gateway VIP to be behind a Context Switch Virtual Server

This would allow organisations with a single internet IP address to host a number of services behind the CSS VIP including Sharefile connector, Access Gateway etc. At present you need two internet IPs as the Access Gateway VIP can’t be behind a CSS VIP on the same Netscaler. The CSS VS would then correctly route traffic based on the incoming host headers (or traffic type if support for incoming ICA sessions was added, which are not http-based)

2. Resultant set of policies view

When troubleshooting Netscaler Gateway configured to allow access from a variety of device types, you end up with a myriad of session and client-less access policies, some bound to the Netscaler Gateway VIP, others to AAA user groups and others possibly bound globally (e.g. the Netscaler Gateway defaults)

Troubleshooting any connectivity issue becomes very hard when you can’t see which policies are being applied to incoming user sessions. A RSOP viewer for “currently connected sessions” showing which policies have been applied, and in what order, would be hugely beneficial when troubleshooting.

3. More flexibility in AAA servers

The latest Netscaler 10.1 release added a third “group extraction” AAA binding option to Netscaler Gateway VIPs. This means that the group that controls access can be in a different directory/AD domain to your primary or secondary authentication directory. I’d like this expanded further so that you can “do more” with this third AAA service, for example query it for particular attributes.

For example the “SSO Name attribute” extraction functionality queries an LDAP authentication server, and then uses the resulting value to authenticate through to StoreFront. But why only StoreFront? I’d like the flexibility of doing this in any AAA server, and choosing how the resulting value is used.

As an example, a username for my cloud-hosted RADIUS account might well be different to my AD login, and whilst there is a way of working around this by populating an unused AD attribute, it would be nice if Netscaler supported this use case out of the box without users having to change the way they log in. In this particular customer example, they had a third non-AD enterprise LDAP directory where various attributes were stored, including the username used for their third party RADIUS service.

4. Improved configuration wizards

There has been an explosion in wizards in recent Netscaler firmwares, and whilst it’s good to allow the novice administrator a faster route to configuring what is a complex device, the way they have been implemented can be improved.

They are not fully restart-able. If something goes wrong part-way through, re-running the wizard often then fails due to the part-configuration already applied. Your only solution then is to roll back to a previous device-wide configuration and start again.

A better approach would be to collect all the information, check the existing configuration for anything that might cause it to fail, then provide all the configuration commands that are about to be executed (much like XenDesktop shows you the PowerShell behind every command in the console) I know you can extract this information from the log post-change, but providing the actual configuration the wizard will create will help understand what changes it is making.

As an example, here is the configuration created by the Cloud Bridge load balancing wizard. Free beer to anyone who can tell me what every command actually does in the comments 🙂

set lb parameter -preferDirectRoute NO -sessionsThreshold 150000
add server x.x.x.x y.y.y.y
add service BR_LB_SVC_x.x.x.x y.y.y.y ANY * -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip YES -useproxyport NO -sp OFF -cltTimeout 120 -svrTimeout 120 -CKA NO -TCPB NO -CMP NO -downStateFlush DISABLED -appflowLog DISABLED
add lb vserver BR_LB_VS_UK ANY * * -persistenceType NONE -Listenpolicy "(SYS.VSERVER(\"BR_LB_VS_UKLab\").STATE.EQ(UP)&&((CLIENT.TCP.OPTIONS.TYPE_NAME(REPEATER).EXISTS&&CLIENT.TCP.REPEATER_OPTION.IP.EQ(x.x.x.x))||CLIENT.IP.DST.IN_SUBNET(y.y.y.0/27)))" -Listenpriority 0 -m MAC -cltTimeout 120 -downStateFlush DISABLED -l2Conn ON -appflowLog DISABLED
add ns acl BR-TCP-ALLOW-ACL ALLOW -protocol TCP -priority 10 -kernelstate SFAPPLIED61 -logstate ENABLED
add ns acl BR-BRIDGE-ACL BRIDGE -priority 20 -kernelstate SFAPPLIED61 -logstate ENABLED
set uiinternal LBVSERVER BR_LB_VS_UKLab -rule "x.x.x.x%y.y.y.y%z.z.z.0/27"

5. Provide console access to the AAA log

Troubleshooting authentication issues on Netscaler is a very common task, and having to launch a ssh session, drop out to the shell, then cat /tmp/aaad.debug is a  very user-unfriendly way of accessing a very common log file.

Access to this log should be provided via the Diagnostics area of the console, or even via a view in the Dashboard, and the output should be rationalised to remove the debug entries that currently appear (and easily confuse) every 10 seconds or so.

6. DNS-based CSS traffic routing

OK I know the title says five, but I requested this a while ago so it’s worth a reminder! I had a use case where a Netscaler was load-balancing a number of Apache web servers, each hosting many hundreds of websites. As part of the regular maintenance program, users domains were migrated between back-end web servers to facilitate upgrades. At present, the Netscaler has to be hard-coded to which back-end Apache server a particular incoming hostname should be sent to via a CSS VS. This results in long pattern-sets containing lists of hundreds of hostnames to perform a look-up.

What I’d like is an expression than can determine the correct back-end service to use, based on the results of a DNS query. As accounts were moved between Apache servers, various DNS records were updated to reflect their new “home” server.

e.g. something like

DNS.LOOKUP(hostname).RECORD(record).SERVER(dns_server).EQ

which you can then use in a CSS policy binding to route traffic:

DNS.LOOKUP(HTTP.REQ.Hostname).RECORD("A").SERVER("8.8.8.8").EQ(mytargetserver_ip)

7. Retrieve LDAP attributes from the appliance

A very common way to test your LDAP AAA server is set up correctly is to use the “Retrieve attributes” feature.
Retrieve LDAP attributes

 

A little-known fact about this feature is that it’s your workstation admin client that retrieves the LDAP attributes and not the Netscaler.

This means it’s prone to failure from a number of reasons:

  •  if your admin workstation doesn’t have direct network connectivity to the LDAP server that you are configuring.
  • If the LDAP server is actually a load-balanced VIP on the Netscaler. I often setup a LB VS on the Netscaler to load balance multiple AD domain controllers to provide some LDAP HA, and then point my LDAP server at the VIP. Given most Netscalers get deployed into a DMZ, it’s unlikely your client workstation has direct connectivity into a DMZ to retrieve the attributes and test connectivity.

Given I used to use this feature more to test connectivity than to actually pre-populate the fields with attribute names, it would be more useful if it was the Netscaler that made the connection to the LDAP server. This would then use the correct SNIP/MIP, test the IP routing, firewall rules etc and better reflect your actual configuration rather than giving the impression connectivity is OK because it’s actually your client that can connect.

 8. Retire the Java GUI

Citrix have slowly been moving more and more functionality into the HTML admin GUI in each major release, but there’s still a large chunk of administrative actions that still require a Java client (and thus the associated Java management ports). I still get frequent messages from the admin console that it needs to “re-sync” it’s configuration as it thinks changes have been made in one GUI but need to be reflected in the other. This is a pain, as is opening up specific ports in firewalls just for the Java console.

There are also numerous issues with Java components stopping working when Oracle release a new JVM client, and it’s rather complex to assign correctly signed certificates to prevent numerous Java warnings about untrusted components.

Interestingly, Citrix still provide a complete 100% Java GUI alongside the HTML one, which is often easier to use than the default mixed HTML+Java. See my other blog post on how to switch to this.

 

 

What are your top Netscaler feature requests? Agree with mine or have some more of your own? I’d love to hear about them via the comments.

Leave a comment

You must be logged in to post a comment.

%d bloggers like this: