Netscaler Load Balancing for vCD 9

As mentioned in my previous post, after my upgrade to vCloud Director version 9, I was unable to access vCD via the load balanced virtual IP.  We use a Netscaler HA pair for load balancing in this environment, and since I was able to hit the individual vCD cells just fine, this is where I focused my efforts.  According to Netscaler, the virtual services were up and everything appeared to be in line.  Working with Citrix support, we began looking at SSL Parameters and Cipher suites.  I’ve never had to mess with those settings beyond the default before, but just the mention of it made a light bulb go off.  I remembered glancing over something about SSL in the vCloud Director 9 Release Notes, and immediately pulled that back up while looking at the Netscaler config.  Within a section called “Supported Security Protocols and Cipher Suites” I noticed only TLS version 1.1 and 1.2 are supported with vCD 9.  The Netscaler config at that time showed defaults that had worked in all previous versions.

2017-10-03 13_59_25-10.10.3.13 - Remote Desktop Connection

In addition to that, under the load balanced service I noticed the “DEFAULT_BACKEND” Cipher Suites configured.  These are settings I never had to change through the history of upgrading vCD.

2017-10-03 14_01_08-10.10.3.13 - Remote Desktop Connection

Based on the release notes, I created a new Cipher Suite specific for vCloud Director and did my best to match up the way they appeared on the VMware website versus the way Netscaler presented them.  I was only able to match up 7 of the cipher suites relatively easily, but figured that would be a good starting point.  I then changed my load balanced services to remove the default group and add in the vCloud Director group.

2017-10-04 14_50_18-10.10.3.13 - Remote Desktop Connection

Then I changed the SSL parameters by unchecking SSLv3, TLSv1 and checking TLSv11, TLSv12.

2017-10-04 14_53_23-10.10.3.13 - Remote Desktop Connection

Once these changes were made, we noticed that the https monitor for the service was down because it hadn’t received a code 302.  We had the default response code of 200 listed in the monitor, so we added 302 in as a second response code.

2017-10-04 14_51_31-10.10.3.13 - Remote Desktop Connection

With all the new settings in place, we finally saw a successful monitor response from HTTP code 302, and the vCD portal was once again available via the load balanced VIP and external FQDN pointed back to the Netscaler VIP.

2017-10-03 14_18_13-10.10.3.13 - Remote Desktop Connection

Leave a Reply

Your email address will not be published. Required fields are marked *