The purpose of this post is to dive a little deeper into the NetScaler Gateway settings with StoreFront, since this is another component that changed a lot from the Web Interface world.  As a quick reminder, with Web Interface, you could only define a single NetScaler Gateway (URL + callback pair) per site in the “Secure Access” settings and you had the option to either perform authentication at the NetScaler Gateway or authentication at Web Interface with just ICA proxy traffic going through the defined NetScaler Gateway.  With StoreFront, we changed both of these things radically:

  • It is possible to define multiple NetScaler Gateways per Store (IIS site).  Gateways are defined and listed independently of the Store configuration.
  • By default, StoreFront requires that authentication occur at the Gateway for ICA traffic to be proxied by the Gateway.  When you define a NetScaler Gateway in the StoreFront console, “Passthrough from NetScaler Gateway” authentication is automatically enabled.

Now, the fact that both of these things are technically possible does not mean that they should be done or must be done in all cases and some of the finer technical details behind these settings that we have encountered in the field will be the focus of this post.

Let’s start with the number of NetScaler Gateways per StoreFront Store.  With Web Interface, every Gateway + callback combination required a new website so it was not possible to route users entering from different NetScaler Gateways through the same website.  It was possible to route internal and external users using a single Gateway address through the same website using IP ranges in Web Interface to identify internal vs external users, but that was it.  This is, by the way, something StoreFront can do as well, but differently: it uses “beacons” defined in the console when users connect via a Receiver client (Receiver attempts to contact the “internal beacon” and if it fails, assumes you are connecting externally via a NetScaler Gateway).

Back to Gateways: for our larger customers with multiple NetScaler devices for high availability and scale and/or multiple NetScaler Gateway URLs supporting different lines of business, this could easily result in a lot of Web Interface websites to manage.  The ability for StoreFront to aggregate potentially all these Gateway definitions into a single website may seem like it is too good to be true, so let’s dive a little deeper into how this is accomplished with StoreFront.

If we are going to be defining multiple NetScaler Gateways per website, StoreFront needs a way of correctly identifying traffic from each Gateway so it can route the traffic to/from the Gateway (such as for callback) correctly.  If you look at the Gateway Settings screen in StoreFront, shown below, the options for doing so are the URL and the SNIP field.  StoreFront gets several IP addresses and the Gateway FQDN passed to it as HTTP headers (XCITRIXGATEWAY, XCITRIXVIA, XCITRIXVIAVIP, and XFORWARDEDFOR) and uses this information to identify the Gateway a user came in from.  If you are having issues with StoreFront and Gateway integration, a great first step is to turn on trace logging on StoreFront, login through NetScaler Gateway, and take a look at the Authentication log on the StoreFront server.  You will see the values of these headers and which Gateway StoreFront has chosen based on that information.

1.  NetScaler Gateways behind transparent GSLB:  If several Gateways are behind transparent GSLB, that means the URL will be the same and is no longer a good differentiator so we need to rely on an IP address.  Putting the actual SNIP in the “SNIP” field will only work if the NetScaler device hosting the Gateway vServer is communicating directly with the StoreFront servers.  If there is another tier of load balancers sitting between the Gateway and the StoreFront servers (either NetScaler or third party) as is the case with most of our larger environments, then the StoreFront servers will not see the SNIP.  In this case, the Gateway vServer VIP should be entered in this field.  The need to enter the VIP is documented on our eDocs page, but it is somewhat hidden and we still see a lot of confusion in the field about what this SNIP field means, so I am trying to set the record straight here.  The Gateway vServer VIP is passed to StoreFront by means of the XCITRIXVIAVIP header, which was an enhancement to the NetScaler code and based on testing appears to be passed as a standard with any 10.1 or later build.  With earlier builds of NetScaler, you may need to bind a custom rewrite policy to the Gateway vServer to add this header as follows, after which you can specify the VIP in the SNIP field and everything works.

“add rewrite action <name> insert_http_header X-Citrix-Via-Vip “\”<IP of the Gateway>\”” -bypassSafetyCheck YES”

2.  “Default appliance” setting with Receiver:  Although NetScaler Gateways are defined separately from the Store configuration in the StoreFront console, in order for a user to login successfully via one of these Gateways to StoreFront, the Gateways must be enabled within the Store (simple enough – if you want users to be able to log into the Store from all Gateways, you enable all Gateways) and a “default appliance” must be defined – this is the tricky part – as shown in the screenshot below.

For web browser-based access, the “default appliance” setting has no impact.  For native Receiver access, this setting is downloaded to Receiver on connection to the Store as part of the Store configuration and that Gateway is used thereafter by default.  If all defined Gateways share the same URL via GSLB, then again, this has no impact (Receiver just uses that Gateway definition to see which URL to query).  If the Gateways have different FQDNs and you enable them all for a Store, then whichever one is defined as the default will be used by all Receiver clients on first connect.  This is problematic if you have two distinct user communities using different FQDNs that you want to aggregate into the same Store (for management simplicity) and they are using Receiver clients.  For example, if you have and and the Gateway selected as the default for the Store is “myapps.”  Any user that enters “myvdi” into Receiver during first time setup will be re-routed to “myapps” as soon as they hit StoreFront and be prompted to authenticate again.  The cleanest way therefore to deal with multiple Gateway FQDNs and native Receiver clients is via distinct Stores or via distinct StoreFront server groups.  Again, fairly specific scenario, but this is another setting that we find is not very well understood by the field.

Moving onto the Gateway authentication requirement.  We have some customers that have implemented NetScaler Gateway purely as an ICA proxy to simplify firewall rules but are doing authentication at Web Interface.  More recently, we have also gotten customers who are interested in collecting HDX Insight data for internal users (which means the ICA traffic has to pass through a NetScaler) without forcing their internal users to explicitly authenticate at a Gateway.  By default, StoreFront assumes that only external users will be coming in through a Gateway and authentication will be occurring there – it is not possible to define a Gateway without enabling “Passthrough from NetScaler Gateway” authentication.

Enter Gateway Optimal Routing, which is another config-file based setting, loosely grouped with the multi-site settings.  The Gateway Optimal Routing settings assign a Gateway per XenApp/XenDesktop farm/site, overriding anything else defined in the console, and are detailed in eDocs here.  There is an optional “enabledOnDirectAccess” parameter that enforces the use of a particular Gateway for a farm/site (or set of farms/sites) such that any user session destined for that farm/site (or set of farms/sites), whether that user came in through that Gateway or not, gets routed back out through that Gateway.  There are two possible uses for these settings: (1) to route users to the Gateway closest to the backend XenApp/XenDesktop farm/site they are connecting to, essentially mapping a preferred Gateway to every farm/site StoreFront is enumerating regardless of the user entry point, and (2) to achieve the HDX Insight data collection goals without implementing Gateway authentication (so users can still leverage domain passthrough authentication at StoreFront, but get routed back through a specified Gateway, which will send ICA metrics to HDX Insight for monitoring).  It does not apply to all use cases as there are some inherent assumptions about the relative locations of your XenApp/XenDesktop sites and your NetScaler Gateways and this should not be configured in a way that results in all your users going through a single Gateway.  But, we have seen it used as a creative solution for gathering HDX Insight metrics for internal users at some of our customers recently.

So to summarize the lessons learned regarding Gateway integration with StoreFront:

  • StoreFront generally will require fewer websites than Web Interface due to consolidation of Gateway definitions
  • Any IP that uniquely identifies a Gateway can be specified in the SNIP field (not just the SNIP).  When the StoreFront servers are behind a separate tier of load balancers from the Gateways and several Gateways share a URL due to GSLB, generally specifying the Gateway vServer IP (VIP) works best.
  • Define a Store or Server Group per unique Gateway URL if Receiver clients will be used to connect externally though a Gateway to StoreFront to allow for the correct definition of the default Gateway.
  • The Gateway Optimal Routing settings can be used to leverage the Gateways for only ICA Proxy without requiring Gateway-based (explicit) authentication.  Some customers have used this to allow their internal users to leverage passthrough authentication directly at StoreFront while still routing the traffic back through a Gateway and collecting HDX Insight metrics.