No GUI? No Problem!

I’ve been trying to broaden myself lately…

A few months ago, I helped a customer with a project – they added another NetScaler to their portfolio to help enhance user experience with ShareFile in other parts of the world. After all, it doesn’t make sense to send traffic halfway around the world just to have it come back to your neighbor’s, right?

I had a good understanding of how NetScaler fit into the ShareFile story at that point, but had no idea the power and versatility of the appliance until later when I would be studying for my networking certificate – something I may discuss at a later date, but that’s not the scope of this post.

I get on the phone with the customer and am ready to assist in setting up their new NetScaler to load balance the ShareFile traffic going into a site in the Middle East. My contact is very thankful and appreciative that I’m helping (this wasn’t a sales opportunity for us)… then he hits me with the hard stuff: “I only work on our NetScaler in the CLI.”

$#!T!!!

We come to a compromise – I tell him what needs to be done, he knows how to script it out – perfect. I also show his upcoming replacement how to configure through the web GUI for their future needs as he doesn’t have experience with either CLI or the GUI. (There’s a wizard in NetScaler 10.5+ to configure ShareFile load balancing/content switching).

We part ways with plans to reconnect so that I can learn a little CLI from the NetScaler wizard at said customer. When I say wizard, I mean he can operate and knows our product better than some of my colleagues. These plans, however, fall through – bummer.

Fast forward a few months – I’m on another call with a new customer. They are using an older version of NetScaler that does not have a ShareFile wizard in the GUI. Looks like we’re going manual. But wait.. we’re also missing a few menu options for features like content switching and http callouts. Hmmm. Looks like we’re going to the CLI!

That brings us to the point – how can we configure NetScaler to content switch and load balance ShareFile traffic through the CLI? Let’s talk about it:

Before we get into configuring NetScaler for ShareFile, let’s first establish how traffic flows: ShareFile traffic comes to the external firewall utilizing a provided FQDN from the customer. Traffic can than be NATed to a DMZ IP that we would set on the Content Switching vserver. Based upon the type of request coming to the switch, traffic would be forwarded to the proper Load Balancing vserver (When ShareFile is used with Network Share/SharePoint Connectors, there are load balancers to support each type of traffic – ShareFile Data and Connector Data). If validated, traffic continues on to the StorageZone Controller; if traffic cannot be validated, it is then dropped in the DMZ. There’s also an optional authentication piece utilizing AAA on NetScaler when using Connectors that binds to the Connector LB vserver.

And now, the moment we’ve all been waiting for:

First things first, we need to create our server. You can do so with the following command:

add server  

Once our server is created, we’ll create the service:

add service   SSL 443

Now that we have the service created, we’ll create our load balancing vservers. In this example, we are creating two load balancing vservers – one for ShareFile data and one for Connector data. Since we are using a content switch, our load balancing vservers do not need to be addressable, so we will leave them without an IP address.

We’ll start with the ShareFile vserver, bind it to our service and bind our SSL certificate to it.

add lb vserver  SSL -persistencType SSLSESSION -lbMethod TOKEN -rule "HTTP.REQ.URL.QUERY.VALUE(\"uploadid\")"
bind lb vserver  
bind ssl vserver  -certkeyName 

Next, we’ll create our Connector load balancing vserver and do the same: bind the service and the cert.

add lb vserver  SSL -persistenceType COOKIEINSERT -timeout 240
bind lb vserver  
bind ssl vserver  -certkeyName 

Alright, we have our load balancing configuration complete for now – now let’s move onto content switching. To begin, we’ll create our content switching policies: depending on the request URL, traffic will be sent to our ShareFile LB vserver if the URL doesn’t contain “cifs” or “sp,” whereas traffic that does contain “cifs” or “sp” will be forwarded to the Connector LB vserver. Here are the policies:

add cs policy  -rule "HTTP.REQ.HOSTNAME.CONTAINS(\"\") && HTTP.REQ.URL.CONTAINS(\"/cifs/\").NOT && HTTP.REQ.URL.CONTAINS(\"SP/\").NOT"
add cs  -rule "HTTP.REQ.HOSTNAME.CONTAINS(\"\") && HTTP.REQ.URL.CONTAINS(\"/cifs/\") || HTTP.REQ.URL.CONTAINS(\"SP/\")"

So now we have our policies, but what good are they without a content switching vserver? None! Let’s add one and bind those policies we just created:

add cs vserver  SSL  443
bind cs vserver  -policyName  -targetLBVserver  -priority 100
bind cs vserver  -policyName  -targetLBVserver  -priority 110
bind ssl vserver  -certkeyName 

Almost there – but first, we have to tell our NetScaler how to validate traffic. To do this, we’ll set up HTTP callouts (callout and callout_y) and a responder policy to respond to said callouts. These callouts will check the requesting URL for a valid HMAC – based on the response from the StorageZone Controller, the responder policy will either allow traffic through or drop it in the DMZ:

add policy httpCallout 
set policy httpCallout  -vserver  -returnType BOOL -hostexpr  -urlstemexpr "\"/validate.ashx?RequestURI=\" + HTTP.REQ.URL.BEFORE_STR(\"&h\").HTTP_URL_SAFE.B64ENCODE + \"&h=\"+ HTTP.REQ.URL.QUERY.VALUE(\"h\")" -scheme http -resultExpr "HTTP.RES.STATUS.EQ(200).NOT"
add policy httpCallout _y
set policy httpCallout _y -vserver  -returnType BOOL -hostexpr  -urlstemexpr "\"/validate.ashx?RequestURI=\" + HTTP.REQ.URL.HTTP_URL_SAFE.B64ENCODE + \"&H=\"" -scheme http -resultexpr "HTTP.RES.STATUS.EQ(200).NOT"
add responder policy  "HTTP.REQ.URL.CONTAINS(\"&h=\") && HTTP.REQ.URL.CONTAINS(\"/crossdomain.xml\").NOT && HTTP.REQ.URL.CONTAINS(\"/validate.ashx?requri\").NOT && SYS.HTTP_CALLOUT() || HTTP.REQ.URL.CONTAINS(\"&h\").NOT && HTTP.REQ.URL.CONTAINS(\"/crossdomain.xml\").NOT && HTTP.REQ.URL.CONTAINS(\"/validate.ashx?requri\").NOT && SYS.HTTP_CALLOUT(_y)" DROP
bind lb vserver  -policyname  -priority 100 -gotopriorityexpression END -type REQUEST

That’s it! we have successfully configured NetScaler to load balance and Content switch ShareFile traffic!!

As I mentioned above, there is the ability to leverage NetScalers AAA feature in conjunction with the CIF/SP load balancer for an added layer of security – if you have this feature licensed, you can follow the next few steps to create an LDAP policy on your NetScaler and bind it to a AAA vserver, along with binding the AAA vserver to the CIF/SP LB vserver for authentication. Please note, the AAA vserver requires an unused DMZ IP:

add authentication ldapAction  -serverIP  -ldapBase "DC=,DC=" -ldapBindDN  -ldapBindDnPassword  -encrypted -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -ssoNameAttribute userPrincipalName
add authentication ldapPolicy  ns_true 
add tm sessionAction  -ssoDomain 
add tm sessionPolicy  ns_true 
add authentication vserver  SSL  -AuthenticationDomain 
bind authentication vserver  -policy  -priority 100
bind authentication vserver  -policy  -priority 100
bind ssl vserver  -certkeyName 

Once the AAA vserver and LDAP settings are configured and bound, we’ll bind them to the LB vserver:

set lb vserver  -persistenceType COOKIEINSERT -timeout 240 -authn401 ON -authnVsName 

Congratulations – you have configured your NetScaler for ShareFile!!