December 7, 2012 Leave a comment
One excellent feature of Citrix NetScaler is the SSL Offload capabilities. Based on the MPX specs (Physical appliance), they all include a Cavium SSL accelerator card, this card has the ability to handle SSL encryption/decryption cycles using a hardware card, rather than consuming valuable CPU resources.
After reading and speaking with fellow Citrix engineers, the VPX (Virtual appliance) can also have the SSL offload feature enabled (I always thought it didn’t since there is no SSL card), however as there is no Cavium card, the SSL offload performance is not as high as an MPX appliance, and generally consumes a ton of CPU, hence it can severely impact the scalability of servers that host content requiring SSL encryption (be careful when you are sizing your NetScaler)
Here are some real world examples of how this is used:
- Microsoft Outlook Web Access/Client Access (Ah that Source IP Mike!)
- Inspection of SSL traffic and switching based on content
- SSL based websites (no payment information exchanged*) – Been looking at PCI initiatives very closely lately
“*When payment information is exchanged, it is usually mandated that the data cannot be viewed in transit, this is a requirement of PCI-DSS compliance” – Citrix Tech
The NetScaler can instead use SSL-Bridge for these types of transactions, and not utilize the SSL Offload technology. What this means is the NetScaler will simply pass the SSL traffic directly to your back-end servers, and not act as the SSL terminator.
Now… let me thank Citrix and Simon Barnes from ITVCE for sharing this information.
SSL offload is designed to function in a similar manner to the below image:
In essence all encryption/decryption between the client and server is handled by the NetScaler SSL offload vServer. Once the data has been decrypted it is then sent on the destination service in plain text HTTP.
This configuration assumes that an SSL certificate already exists on the NetScaler for the chosen FQDN. The SSL Certificate is named “SSLapp”.
1. Create a back-end HTTP service
The first step in creating a new service is to create a server object, This is achieved by using “SSL Offload -> Servers” and then select “add”. The resulting item is purely an object that the NetScaler references in further configuration options. The name field does not need to match the hostname of the server, but it is recommended. In this example the webserver is named WinSvr01 and has an IP address of 10.99.0.5
Now that a server object exists, you can create a service object to reflect the HTTP service that is running on this web server.
A NetScaler service consists of a server object (created in the previous step), a protocol, port and a monitor. The monitor is used to determine if the service is available, in the event that the service is unavailable the NetScaler will mark the service as down, removing it from load balancing decisions.
In this example we are running a HTTP service (using default of port 80) on the previously created server object, whilst using a standard HTTP monitor to confirm that HTTP services are responding with a response code of “200” – this is HTTP for “ok”.
2. Create your vServer
Now that a service exists, you are ready to present the service to the outside world. This is achieved using a NetScaler virtual server (vServer). The first step is to create the object and provide the following information:
- IP Address
- Bound services
In this example we only have a single service to bind to the vServer, however in a production installation there may be 20 backend webservers all delivering the content, if this was the case these could be added in to a service group and then bound to the vServer, load balancing would then be used to ensure that the load is distributed to services that are UP and are able to service the client’s request.
The IP address that is added to the vServer here will be used by clients to connect to the backend services:
A certificate must also be bound to the vServer, this is the certificate that the vServer will present for client connections.
Client connections should now be directed to the vServer’s IP address – 10.99.0.231. The vServer will present the SSL certificate when a connection is made using HTTPS (TCP 443), any encryption/decryption of data will be processed using the NetScaler’s built in Cavium card.
If the NetScaler is configured as a HA pair and the primary unit’s Cavium card fails, then HA failover will be invoked and the secondary unit will become the primary.
NetScaler 10 build 69.4 Bug
The GUI appears to incorrectly report the status of a feature, offering only the “disable” option for each feature. I have seen scenarios whereby the above configuration has been completed and the vServer immediately appears down, even though everything appears correctly configured.
The first thought is that SSL may not be enabled; checking in the GUI will only show you the option to disable the feature:
To view the reason that the vServer is down you can simply connect using SSH and then issue the following command:
As you can see in the above screenshot the SSL feature is disabled, causing the vServer to appear down. Enable the SSL feature using the following command:
The vServer will immediately come online: