Citrite 239

Since Citrix acquired Netscaler, there haven't been any major changes to the Netscaler operating system in terms of Access Suite integration. Netscaler was already a very mature and successful product with its own road map already well defined. Presentation Server integration is now part of that road map but it's going to take a while. So unlike Access Gateway, Netscaler cannot fully replace a Secure Gateway server because the Netscaler box doesn't yet understand things like STA ticketing, CGP and ICA.

Secure Gateway expects the following sorts of traffic to arrive on port 443:

1. HTTPS, which SG can relay to a Web Interface server
2. ICA in CGP in SSL, where the CGP layer includes a ticket that must be validated by a Secure Ticketing Authority (STA), or
3. ICA in SOCKS in SSL, where the SOCKS layer includes a ticket that must be validated by a Secure Ticketing Authority (STA)

When traffic arrives, SG unwraps the SSL layer and then deals with the payload based on those three use cases. Recent ICA clients (since 9.0) will send ICA in CGP in SSL; older ICA clients use SOCKS. The CGP protocol is what enables session reliability through a secure gateway server. See my Secure Gateway Troubleshooter's Guide for more details on this.

Looking at the SG server's httpd.conf file, it is easy to disable the SSL expectation. SG 3.0 is based on Apache, and there are three "VirtualHost" sections in the httpd.conf file. For example:

#Gwy Settings - CGP

<VirtualHost 172.16.30.102:443>

ServerName sg.company.com:443

CgpProtocol On

RequireTicket On
CGPHandshakeTimeout 100000
RegisterProtocol CGP
UseConnCounter CONCURRENT_CONN_LIMIT

# SSL Params
SSLEngine On
SSLCertificateHash 6b5c6b264e0a07d0fbd30816cf68f13371076d1d
SSLProxyEngine On

...

You can turn off SSL for each virtual host by simply changing the line "SSLEngine On" to "SSLEngine Off".

If you do that for all three virtual host sections and then restart the SG service, you will have a Secure Gateway service that now expects these sorts of protocols to arrive on port 443:

1. HTTP, which SG can relay to a Web Interface server
2. ICA in CGP, where the CGP layer includes a ticket that must be validated by a Secure Ticketing Authority (STA), or
3. ICA in SOCKS, where the SOCKS layer includes a ticket that must be validated by a Secure Ticketing Authority (STA)

Now you're ready to set up a Netscaler and do the SSL offload.

1. Create a TCP service entity for each Secure Gateway box on port 443
2. Put a certificate on the Netscaler and create an SSL Offload virtual server that uses the SSL_TCP protocol and the Least Connections load balancing method. Persistence is not required for ICA connections. Add the TCP services you created in step 1.
3. Configure web interface to use the FQDN of the certificate you used in step 2 as the Secure Gateway FQDN

It would be a good idea to create a separate SSL offload virtual server just for the web interface traffic too, which relays HTTP to the WI servers on port 80 instead of relaying that traffic through the hacked up secure gateway service.

I tried this little experiment and it works. The protocol stacking looks like this:

Browser --[HTTPS]--> Netscaler --[HTTP]--> WI --[XML]--> Presentation Server

ICA Client --[ICA+CGP+SSL] --> Netscaler --[ICA+CGP]--> SG --[ICA+CGP]--> Presentation Server

Some day the Netscaler will probably have all the Secure Gateway functionality, like the Access Gateway appliance does today. Until then, this experimental topology may provide you with better throughput and allow you to get more users per SG server by offloading the encryption tasks to a Netscaler.

Jay