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:
add server <server name> <internal IP address of StorageZone Controller>
Once our server is created, we’ll create the service:
add service <service name> <server name> 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 <ShareFile vserver name> SSL -persistencType SSLSESSION -lbMethod TOKEN -rule "HTTP.REQ.URL.QUERY.VALUE(\"uploadid\")" bind lb vserver <ShareFile vserver name> <service name> bind ssl vserver <ShareFile vserver name> -certkeyName <certificate key name>
Next, we’ll create our Connector load balancing vserver and do the same: bind the service and the cert.
add lb vserver <CIF/SP vserver name> SSL -persistenceType COOKIEINSERT -timeout 240 bind lb vserver <CIF/SP vserver name> <service name> bind ssl vserver <CIF/SP vserver name> -certkeyName <certificate key name>
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 <ShareFile Policy Name> -rule "HTTP.REQ.HOSTNAME.CONTAINS(\"<StorageZoneControllerFQDn>\") && HTTP.REQ.URL.CONTAINS(\"/cifs/\").NOT && HTTP.REQ.URL.CONTAINS(\"SP/\").NOT" add cs <CIF/SP Policy Name> -rule "HTTP.REQ.HOSTNAME.CONTAINS(\"<StorageZoneControllerFQDn>\") && 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 <CS vserver name> SSL <NATed IP address> 443 bind cs vserver <CS vserver name> -policyName <ShareFile Policy Name> -targetLBVserver <ShareFile vserver name> -priority 100 bind cs vserver <CS vserver name> -policyName <CIF/SP Policy Name> -targetLBVserver <CIF/SP vserver name> -priority 110 bind ssl vserver <CS vserver name> -certkeyName <certificate key name>
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 <callout name> set policy httpCallout <callout name> -vserver <ShareFile vserver name> -returnType BOOL -hostexpr <StorageZone IP> -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 <callout name>_y set policy httpCallout <callout name>_y -vserver <ShareFile vserver name> -returnType BOOL -hostexpr <StorageZone IP> -urlstemexpr "\"/validate.ashx?RequestURI=\" + HTTP.REQ.URL.HTTP_URL_SAFE.B64ENCODE + \"&H=\"" -scheme http -resultexpr "HTTP.RES.STATUS.EQ(200).NOT" add responder policy <responder policy name> "HTTP.REQ.URL.CONTAINS(\"&h=\") && HTTP.REQ.URL.CONTAINS(\"/crossdomain.xml\").NOT && HTTP.REQ.URL.CONTAINS(\"/validate.ashx?requri\").NOT && SYS.HTTP_CALLOUT(<callout name>) || HTTP.REQ.URL.CONTAINS(\"&h\").NOT && HTTP.REQ.URL.CONTAINS(\"/crossdomain.xml\").NOT && HTTP.REQ.URL.CONTAINS(\"/validate.ashx?requri\").NOT && SYS.HTTP_CALLOUT(<callout name>_y)" DROP bind lb vserver <ShareFile vserver name> -policyname <reponder policy name> -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 <ldap server name> -serverIP <Internal IP of AD server> -ldapBase "DC=<domain>,DC=<domain extension>" -ldapBindDN <email@example.com> -ldapBindDnPassword <admin password> -encrypted -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -ssoNameAttribute userPrincipalName add authentication ldapPolicy <ldap policy name> ns_true <ldap server name> add tm sessionAction <session profile name> -ssoDomain <domain.tld> add tm sessionPolicy <session policy name> ns_true <session profile name> add authentication vserver <AAA vserver name> SSL <DMZ IP of AAA vserver> -AuthenticationDomain <domain.tld> bind authentication vserver <AAA vserver name> -policy <ldap policy name> -priority 100 bind authentication vserver <AAA vserver name> -policy <session policy name> -priority 100 bind ssl vserver <AAA vserver name> -certkeyName <certificate key name>
Once the AAA vserver and LDAP settings are configured and bound, we’ll bind them to the LB vserver:
set lb vserver <CIF/SP vserver name> -persistenceType COOKIEINSERT -timeout 240 -authn401 ON -authnVsName <AAA vserver name>
Congratulations – you have configured your NetScaler for ShareFile!!