in NetScaler Gateway, Traffic Management

One Content Switch to rule them all!

One content switch to rule them allThe Content Switch (CSW) is a beautiful feature that enables you to use a single point of entry – your NetScaler – to host multiple services (like XenDesktop, XenMobile and Sharefile). Based on the content (and context) requested the CSW will direct the traffic to the server offering the best service suitable for the task.

Since I visit sites that restrict outgoing traffic to known ports (sometimes only port 80 and 443), and only have a single IP in my home lab, I needed a solution that allows me to demo several Citrix products using the same entry point. In this article I’ll show you how you can use the CSW to host several Citrix products (XenDesktop, XenMobile and ShareFile) using a single IP and port.

Disclaimer: Parts in this setup are not supported and therefore shouldn’t be used in production environments!


Since I travel to customer sites to demo Citrix products I’d like to access my lab environment in a secure manner. In my lab environment I host several Citrix products I’d like to demo as part of the Mobile Workspace

  • Citrix ShareFile
  • Citrix XenDesktop / XenApp
  • Citrix XenMobile

Besides access to the services itself I’d like to have secure access to a variety of web-based management consoles, for instance:

  • AppController
  • NetScaler Management console (NSIP)
  • XenMobile Device Manager
  • etc.


Content Switch

As a point of entry into the NetScaler I use a CSW for each type of traffic where I have multiple services. That means I have a CSW for http:80 (csw_http)  and ssl:443 (csw_ssl) which will direct traffic to the corresponding service based on the hostname in the request.

In order to access the various services a number of FQDN’s are needed:

Citrix solutions

  • – Citrix XenMobile Device Management
  • – Citrix ShareFile StorageZone
  • – NetScaler Gateway (Citrix XenDesktop)

 Servers (management consoles)

  • etc.


A policy is created for each hostname + CSW combination (you can’t bind the same policy to two CSW’s). Each policy has an expression similar like this:

The only exception is ShareFile where we differentiate between data and connector (see the CSW policy cs_pol_ssl_sf_data and cs_pol_ssl_sf_data in the images below). traffic as explained in CTX139132 


Since the CSW decrypts the SSL packet there are some takeaways you should consider:

  1. Content Switches don’t understand ICA traffic. As a result you can’t content switch “ICA proxy” traffic, the CSW will simply choke when evaluating the policy. This can be mitigated by assigning the NSGW to the Default Load Balancing Virtual Server
  2. Citrix XenMobile Device Manager (XMDM) uses client certificates to authenticate mobile devices. As a result you need to enable client authentication (optional), apply an SSL policy (SSL-policy-XenMobile) and assign the CA certificates (basically the same as when you SSL offload the XMDM)
  3. When the next hop is a SSL virtual server the NetScaler needs to decrypt and encrypt again, increasing the required resources. If traffic is considered “safe” in your DMZ you might want to consider continuing in HTTP



Load Balancing

A CSW always directs traffic to a Load Balancing (LB) Virtual Server. This means you should always create a LB Virtual Server for each service you’d like to offer. For most services this is a normal procedure (for instance for ShareFile and XenMobile) but for other services this requires some tricks.

NetScaler Gateway

Reminder: This is not supported. Don’t try to get support as it’s unsupported Winking smile

A NetScaler Gateway (NSGW) is a Virtual Server which has a virtual IP (VIP) assigned. As a result you can’t “just” load balance NSGW virtual servers. If you’ll try to create a LB Virtual Service for the NSGW the NetScaller will throw an “Address already in use” error.

No worries, there’s a trick to achieve this. Basically we’re gonna fool the NetScaler by making him think he’s load balancing a generic TCP service.  We can achieve this by sending the CSW to an SSL LB Virtual Server (lbvs-SSLVPN-http) which in its turn is sending all traffic to a TCP LB Virtual Server (lbvs-SSLVPN-tcp) which sends its traffic to the NSGW. Sounds complicated, but the picture below makes it easier to understand.

As I said earlier this is not rather efficient, the NetScaler has to process SSL two times. First the content switch (csw_ssl) and then the NSGW (_XD_cag).


PS: The IP is the virtual IP (VIP) of the NSGW and the IP is simply a staging IP.

PS: Technically you could create a NSGW via HTTP (see CTX120639) – to avoid the second SSL – but then the load balancing “trick” won’t work. Let me know in the comments if you fixed that Winking smile


NetScaler Management Console

If you want to access the NetScaler Management Console via the same CSW VIP you need to access the NSIP (NetScaler IP) via a LB Virtual Server. Just like the NSGW this requires a trick. When you add the NSIP as a LB Server the NetScaler will throw an “Operation not permitted” error. This time the trick is easier, just add a LB Server with domain name

Now all you have to do is create LB service and a LB server (non addressable) and you can use the CSW to direct traffic to the NSIP.



Overview / diagram




  • You need a wildcard SSL certificate (* or a Subject Alternative Name (SAN) certificate linked to the SSL CSW virtual server
  • You could use regular SSL certificates for the SSL LB Virtual Servers  (lbvs-appcontroler-4443, lbvs-SSLVPN-ssl and lbvs-XenMobile-8443) and the NSGW (_XD_cag) but a wildcard SSL might be just as easy.

What do you think?


  1. This is a great article. With Netscaler 11.X you dont have to do through as much work for netscaler gateway. Create the policy and configure the action to use NetScaler Gateway Virtual Server and target you NS Gateway. This takes care of ICA proxy as well.

  2. I love the graphs of your work flows. Did you generate them from your code or did you use visio? If generated, which program did you use?