Introduction
NetScaler Insight is a fantastic tool to understand what is actually happening within a HTTP or HDX session for a user, it provides details on the specifics of each user session and that had been the missing component in Citrix deployments until its release. The whole point of using Citrix software is that it is geared up to give the user the best experience when accessing their applications or data from wherever they may be, so when the user has a poor experience it’s important to find the issue and get it resolved quickly. NetScaler Insight is key to that troubleshooting process.
Since it was introduced, the Development team at Citrix have made great strides to enhance the product and extend its functions and scaling capabilities. This blog will look at one of the new features that makes gathering the HDX analytics inside the trusted security zone much easier, by utilizing a SOCKS proxy on the NetScaler running version 11 firmware. The blog will also provide some details of the various options for gathering data.
HDX data collection Options
One thing that has been a constant when designing a solution to gather HDX Insight analytics is the need to have a NetScaler or CloudBridge somewhere in the traffic path, the appliance provides the Appflow detail that Insight then presents this to the administrator. There are were three ways of using a NetScaler to gather this information.
- Using a NetScaler Gateway.
- Transparent mode, either L2 or L3 based.
- Policy based routing or sometimes called lollipop mode.
Also, with the release of 7.4 it’s possible to add a further range of Appflow gathering options using a CloudBridge appliance. These are the options to use CloudBridge.
- Data centre mode.
- Data centre and branch mode.
- In conjunction with single hop NetScaler Gateway.
- In conjunction with double hop NetScaler Gateway
The release of NetScaler version 11 firmware, an additional option has been provided. The SOCKS proxy option is a NetScaler configuration option that will provide an alternative way to gather analytics for a LAN user use case without some of the difficulties associated with L2, L3 or PBR options.
The following document reference includes further details of the various modes in 10.5.
This document reference includes further details of the various modes now in 11.0, which includes Gateway with multi-hop over the 10.5 content.
Assumptions
Throughout the text, it is assumed that:
- NetScaler appliances exist in both DMZ and trusted security zones and have as a minimum the Enterprise feature set.
- The appliances are running version 11.0 firmware, in conjunction with an Insight Centre server is at least the same or higher level of firmware as the NetScaler.
- The user is located inside the security boundary, so he/she is sitting inside the corporate firewall.
Firmware Notes
The 10.5.50.10 release from 2014, added the option for Cache Redirection Insight, this release did not have the HDX protocol option. A later 10.5.56.15 build did then add the option to use the protocol and it naturally then became part of the 11.0 feature set also.
In order to gather network analytic information from their HDX session the administrator can do one of the following architectural options.
NetScaler Gateway deployment Mode
When the user is remote from the data centre and needs to gain access to the Citrix software environment for access to published applications and desktops the connection comes in via a NetScaler Gateway. This is a simple approach from a networking perspective, it does get a bit more complicated when the NetScaler appliances are arranged in double hop arrangement, however, the architectural layout is very similar.
However, in this case the user is located inside the corporate firewall. So it is necessary to create an internal NetScaler Gateway to gather statistics and have the users access that portal. It would work, however it is probably better to use the following option.
Optimal Gateway Routing with Gateway Mode
It is also possible to have a hybrid option for trusted zone users, where trusted zone users are redirected to a NetScaler Gateway seamlessly when they launch their applications. This is done by using a Storefront feature called Optimal Gateway Routing. The Storefront system has some modifications to point the LAN user to an internal NetScaler gateway, as the user launches the Application or Desktop the launch file specifies the Gateway URL. As the user has already authenticated when they logged into the internal (windows domain) network, this happens seamlessly and they just start a session in the normal way. Effectively, the user is redirected upon the launch of the application to the NetScaler Gateway and just starts the HDX session over SSL.
As stated in the text, this would be an internal NetScaler Gateway, it is possible to have the trusted zone users pushed to the DMZ, but it is less than ideal to have trusted users traverse a security zone just to gather analytics.
A side effect of this approach is that the HDX session will be encrypted, when it starts up. This option has the benefits that the Administrator usually has some access to the Storefront and NetScaler system and can easily make the changes to implement this.
More details of the changes to storefront can be found here:
Transparent Modes
When the user is located in the trusted security zone, defined as a LAN user here, the traffic still needs to be seen by the NetScaler in order to gather analytics, what were those other options to gather statistics without using a Gateway?
There are a couple of ways to achieve this, either by routing using L3 or bridging the traffic using L2 mode through the NetScaler appliance. While both options are achievable, there are some downsides. When the network gets more complex troubleshooting and scaling becomes more of a challenge for a L2 setup. For a L3 setup the Netscaler sees all the traffic and reachability of VLANs depends on the NetScaler.
Policy Based Routing
By using something like Policy Based Routing (PBR) external to the appliance, traffic can be selectively pushed to the NetScaler by the network. One of my colleagues, Steven Wright, produced a great blog showing how PBR can be enabled on the network to push ICA traffic via a NetScaler.
/blogs/2015/02/02/how-to-deploy-netscaler-insight-center-with-policy-based-routing/
So the L2 and L3 options suggested do allow the ICA traffic to be analysed with the ICA traffic traversing the NetScaler, this achieves the desired result to gather Appflow information, however it’s just that having the traffic always cross the NetScaler can sometimes be difficult when clients are maybe located in several different parts of the network with different routes to get to the back end systems.
Policy Based Routing, as Steven has shown, is also an option. However, using PBR will need the infrastructure to support it.
Using Optimal Gateway Routing with a NetScaler Gateway also allows the session analytics to be gathered, the session is encrypted which might be determined to be overkill for some deployments.
LAN user via the SOCKS Proxy Option
The new option that has been added in NetScaler 11 firmware is the option to use the NetScaler as a forward proxy server using a Cache Redirection server. This has the benefit that it will not require a NetScaler Gateway and there are no changes to any routing rules to accommodate this option.
The process is pretty simple, the CR server has been revised so that it includes a protocol type of ‘HDX’. When this proxy has been defined it will need to be highly available, as if the proxy is unavailable the application will not launch. The internal NetScaler should be deployed as a HA pair anyway.
To set it up, follow these steps:
- Create an Appflow collector/policy/action.
- Create a Cache Redirection server on the NetScaler.
- Set the type as HDX and define the port, for example use port 8080
- Modify the default launch file on the Storefront or WebInterface server to use the new proxy and port.
Step 1. So the first step in the process is to define the Appflow settings
Create Appflow policy, here are the cli commands:
add appflow collector colector1 -IPAddress <collector IP>
add appflow action action1 -collectors collector1
add appflow policy policy1 true action1
Step 2 and 3. Next create the Socks Vserver of the correct type
Create CR (Socks) vServer, again here is the cli commands
add cr vserver crvs HDX <crvserver IP> <Port> -cacheType FORWARD -cltTimeout 180
bind appflow global policy1 1 END -type ICA_REQ_DEFAULT
Step 4. Modify the default.ica launch file to ensure that new launch files use the new proxy.
This file will be present in “C:\inetpub\wwwroot\Citrix\<Store name>\App_Data”. These configs should be present under both [Applications] and [WFClient] sections in the default.ica file. In terms of client connectivity, the port chosen for the Cache Redirection server needs to be reachable on that port. The port number that is selected is in itself not that important, naturally the reach ability is! Here is the settings for the launch file:
ICASOCKSProtocolVersion=0
ICASOCKSProxyHost=<crvserverIP>
ICASOCKSProxyPortNumber=<Port>
ProxyFavorIEConnectionSetting=Yes
ProxyHost=<crvserver IP>:<Port>
ProxyTimeout=30000
ProxyType=Socks
Storefront Considerations
Using this approach would revise the default launch file for <Store name> as stated above. What if the same Storefront server(s) is/are used for both internal and external users? Would that mean that external NetScaler Gateway users would get analytics gathered when using the forward proxy when the access the system also? Naturally, it would if the same store was defined on the NetScaler configuration. As these users are coming into the system via a Gateway it would make sense to gather the analytics in conjunction with the Gateway. There are two options that would allow this:
1. Create a new store and use that one for external users, this would then require it to be defined within the NetScaler configuration to complete the process. As the default launch file modification is per store, it would naturally have a different, more generic launch file setup.
2. Use the Storefront SDK and pick out the different users when they connect, determine if the user is of type LANUser or of type NetScaler gateway. The SDK has a number of options for changing the behavior of Storefront when a user connects. It will be necessary to have some .Net skills, however Simon Frost has provided some great documentation here to help with that process.
/blogs/2014/04/09/introducing-the-storefront-store-customization-sdk/
Using the SDK does require some coding, however it would allow for the deployment to use just a single store for all users.
So how does it look? Here is a high level view.
Conclusion
NetScaler 10.5 firmware extended the options for gathering analytics information, these have been further enhanced with an additional option to use a NetScaler as a forward proxy within NetScaler firmware version 11.0. This option is a simple way to gather those analytics for trusted zone users and now adds to the other options that were available.
