Citrix Secure Gateway (CSG) poses an interesting set of challenges for ZXTM. The protocol used is actually a SSL-encrypted tunnel of two distinct protocols -- HTTP and ICA. ZXTM can decrypt the SSL layer, demultiplex the encapsulated streams and apply separate traffic management policies to each, before re-encrypting the connection to a Secure Gateway cluster, allowing the system to scale whilst maintaining security.

Deployments using Citrix Web Interface and Presentation Server often have a Citrix Secure Gateway as their single point of contact for connections. Whilst this gives a convenient entry point, no scaling technology is built in, meaning that any such system is bound by the SSL performance of a single CSG. We show here how we can use ZXTM to get arbitrary scalability as well as high availability and better performance.

Technical details

Two virtual servers are used -- one for each of the protocols inside the connection.

Incoming traffic is SSL decrypted and split into ICA and HTTP types. HTTP traffic is 'looped back' onto a separate virtual server and pool for additional processing. The two pools direct traffic to the same three CSG nodes.

Externally facing Virtual Server

The first step is to decrypt the incoming stream, which will be SSL encrypted. Use the Manage a New Service wizard to create a Virtual Server called "CSG default". Use the generic client first protocol and listen on port 443. Set the backend servers to be the Secure Gateway machines that you want to manage traffic to. Turn on SSL decryption for this Virtual Server (Virtual Servers > CSG default > SSL Decryption) and SSL re-encryption for the associated Pool (Pools > CSG default > SSL Settings). Change the load balancing algorithm to Least Connections (Pools > CSG default > Load Balancing) to load balance more effectively.

This step simply passes traffic through to a load balanced pool of CSGs which is sufficient for the long-lived ICA connections, but not HTTP traffic (session persistence is needed to allow the Web Interface to work).

Loopback Virtual Server

Next, you will need to create a second Virtual Server specifically to manage the HTTP part of the connections. This is achieved using a loopback Virtual Server -- use the wizard again to create a VS called "CSG HTTP", and this time use the HTTP protocol, and have it listen on a different port. The Pool should have the same set of backends, and have SSL enabled as before. Note that the Virtual Server does not have SSL decryption enabled. Enable Session Persistence on this pool (Pools > CSG HTTP > Session Persistence); a Session Persistence class using Transparent Session Affinity will do nicely here. Performance can be optimized by using Perceptive as the load balancing algorithm.

As this is dealing with HTTP traffic in an SSL connection, set the location!rewrite configuration option to Nothing (This can be found in Virtual Servers > CSG HTTP > Connection Management > Location Header Settings).

You will need a way to reach this loopback Virtual Server from other ZXTMs. Create a further Pool (call it "CSG loopback") whose nodes are the IP addresses of the ZXTMs themselves, using the port that the "CSG HTTP" Virtual Server is listening on. Set the load balancing algorithm to Fastest Response Time for best performance.

Doing the splice

You have now created the framework that is needed to manage each protocol. All that remains is to sort out which connections should be routed where. This can be achieved using a TrafficScript™ rule like this one:

$firstBytes = Request.Get();
if( String.StartsWith( $firstBytes, "GET" ) ||
    String.StartsWith( $firstBytes, "HEAD" ) ||
    String.StartsWith( $firstBytes, "POST" )) {
  Pool.Use( "CSG loopback" );
}

This lets all non-HTTP traffic go straight through to the default pool, whilst allowing HTTP connections to session persist, and gives you scalability and high availability with any number of Citrix Secure Gateway devices.

Brian Cowe [Zeus Systems Engineering] 18 March 2008