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.”
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:
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!!