NetScaler SSL offload with firmware nCore 10 build 69.4

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


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:

  • Name
  • IP Address
  • Port
  • 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 – 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:


About CyberRuiz
Highly motivated with over 12 years experience on Citrix/VMWare/Microsoft/technologies. Exceptional communication skills and team player. CCIA – Citrix Certified Integration Architect. CCEA – Citrix Certified Enterprise Administrator. VCP – VMWare Certified Professional in ESX 2.x, VI3, VI4 MCSE – Microsoft Certified Systems Engineer

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: