The 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!

Services

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 https: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

• enroll.domain.com – Citrix XenMobile Device Management
• sharefile.domain.com – Citrix ShareFile StorageZone
• lab.domain.com – NetScaler Gateway (Citrix XenDesktop)

 Servers (management consoles)

• netscaler.domain.com
• appcontroller.domain.com
• 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:

HTTP.REQ.HOSTNAME.CONTAINS("enroll.domain.com")

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

#--- Content Switch: csw_http ---
   #Create csw
   add cs vserver csw_http HTTP 123.123.123.123 80 -cltTimeout 180

   #Add and bind policies
   add cs policy cs_pol_http_lab -rule "HTTP.REQ.HOSTNAME.CONTAINS(\"lab.domain.com\")"
   bind cs vserver csw_http -policyName cs_pol_http_lab -targetLBVserver lbsv-Redirect_to_https-lab.domain.com -priority 100
   add cs policy cs_pol_http_xm_enroll -rule "HTTP.REQ.HOSTNAME.CONTAINS(\"enroll.domain.com\")"
   bind cs vserver csw_http -policyName cs_pol_http_xm_enroll -targetLBVserver lbvs-XenMobile-http -priority 110
# -------------------------------

# --- Content Switch: csw_ssl ---
   #Create csw
   add cs vserver csw_ssl SSL 123.123.123.123 443 -cltTimeout 180

   #Add and bind policies
   add cs policy cs_pol_ssl_lab -rule "HTTP.REQ.HOSTNAME.CONTAINS(\"lab.domain.com\")"
   bind cs vserver csw_ssl -policyName cs_pol_ssl_lab -targetLBVserver lbvs-SSLVPN-http -priority 130
   add cs policy cs_pol_ssl_sf_data -rule "HTTP.REQ.HOSTNAME.CONTAINS(\"sharefile.domain.com\") && HTTP.REQ.URL.CONTAINS(\"/cifs/\").NOT && HTTP.REQ.URL.CONTAINS(\"/sp/\").NOT"
   bind cs vserver csw_ssl -policyName cs_pol_ssl_sf_data -targetLBVserver lbvs-ShareFile_szc-Data -priority 110
   add cs policy cs_pol_ssl_sf_connectors -rule "HTTP.REQ.HOSTNAME.CONTAINS(\"sharefile.domain.com\") && (HTTP.REQ.URL.CONTAINS(\"/cifs/\") || HTTP.REQ.URL.CONTAINS(\"/sp/\")) "
   bind cs vserver csw_ssl -policyName cs_pol_ssl_sf_connectors -targetLBVserver lbvs-ShareFile_szc-Connector -priority 100
   add cs policy cs_pol_ssl_xm_enroll -rule "HTTP.REQ.HOSTNAME.CONTAINS(\"enroll.domain.com\")"
   bind cs vserver csw_ssl -policyName cs_pol_ssl_xm_enroll -targetLBVserver lbvs-XenMobile-http -priority 120
   add cs policy cs_pol_ssl_netscaler -rule "HTTP.REQ.HOSTNAME.CONTAINS(\"netscaler.domain.com\")"
   bind cs vserver csw_ssl -policyName cs_pol_ssl_netscaler -targetLBVserver lbvs-localhost-HTTP -priority 140
   add cs policy cs_pol_ssl_appcontroller -rule "HTTP.REQ.HOSTNAME.CONTAINS(\"appcontroller.domain.com\")"
   bind cs vserver csw_ssl -policyName cs_pol_ssl_appcontroller -targetLBVserver lbvs-appcontroller-4443 -priority 150

   #Default Load Balancing Virtual Server 
   bind cs vserver csw_ssl -lbvserver lbvs-SSLVPN-http   

   #Certificates
   bind ssl vserver csw_ssl -certkeyName wilcard_domain_com
   bind ssl vserver csw_ssl -certkeyName MDM001_Root-CA -CA -ocspCheck Optional
   bind ssl vserver csw_ssl -certkeyName MDM001_Device-CA -CA -ocspCheck Optional

   #SSL Parameters
   set ssl vserver csw_ssl -eRSA DISABLED -clientAuth ENABLED -clientCert Optional -tls11 DISABLED -tls12 DISABLED

   #SSL Policy
   bind ssl vserver csw_ssl -policyName SSL-policy-XenMobile -priority 100
# -------------------------------

# --- SSL policy: SSL-policy-XenMobile ---
   add ssl action SSL-Action-XenMobile -clientCert ENABLED -certHeader NSClientCert
   add ssl policy SSL-policy-XenMobile -rule CLIENT.SSL.CLIENT_CERT.EXISTS -action SSL-Action-XenMobile
# ----------------------------------------

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

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).

#--- Load Balancing vServer: lbvs-SSLVPN-http ---
   #Create LBVS
   add lb vserver lbvs-SSLVPN-http HTTP 0.0.0.0 0 -persistenceType SOURCEIP -cltTimeout 180

   #Create Server
   add server 172.16.0.252 172.16.0.252

   #Create Service
   add service 172.16.0.252-ssl 172.16.0.252 SSL 443 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -sp ON -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP YES
   set ssl service 172.16.0.252-ssl -tls11 DISABLED -tls12 DISABLED

   #Bind service to LBVS
   bind lb vserver lbvs-SSLVPN-http 172.16.0.252-ssl
#------------------------------------------------

#--- Load Balancing vServer: lbvs-SSLVPN-tcp ---
   #Create LBVS
   add lb vserver lbvs-SSLVPN-tcp TCP 172.16.0.252 * -persistenceType SOURCEIP -cltTimeout 9000

   #Create Server
   add server _XD_cag 10.0.1.252

   #Create Service
   add service "_XD_cag- tcp" _XD_cag TCP * -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -sp ON -cltTimeout 9000 -svrTimeout 9000 -CKA NO -TCPB NO -CMP NO

   #Bind service to LBVS
   bind lb vserver lbvs-SSLVPN-tcp "_XD_cag- tcp"
#-----------------------------------------------

PS: The IP 10.0.1.252 is the virtual IP (VIP) of the NSGW and the IP 172.16.0.252 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

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

localhost

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.

#--- Load Balancing vServer: lbvs-localhost ---
   #Create LBVS
   add lb vserver lbvs-localhost-HTTP HTTP 0.0.0.0 0 -persistenceType NONE -cltTimeout 180

   #Create Server
   add server localhost 127.0.0.1

   #Create Service
   add service "localhost - http" localhost HTTP 80 -gslb NONE -maxClient 0 -maxReq 0 -cip ENABLED cip-header -usip YES -useproxyport NO -sp OFF -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP NO

   #Bind service to LBVS
   bind lb vserver lbvs-localhost-HTTP "localhost - http"
#------------------------------------------------

Overview / diagram

Remarks

• You need a wildcard SSL certificate (*.domain.com) 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.