PowerCLI Stops Working After NSX 6.2.4 Upgrade

NSX LBAs of NSX 6.2.3 TLS 1.0 support is deprecated on Edge Service Gateways. So if you are using load balancer with SSL offload, TLS 1.0 ciphers are no longer being supported and those clients that rely on them will not work anymore.

The supported ciphers can be easily checked with nmap. Here is nmap output to website behind NSX Edge 6.2.2 and 6.2.4 load balancer:

NSX 6.2.2 with TLS 1.0
NSX 6.2.2 with TLS 1.0
NSX 6.2.4 without TLS 1.0
NSX 6.2.4 without TLS 1.0

In my case PowerCLI stopped working and could not connect anymore to vCloud Director endpoint behind the Edge load balancer. The error was not very descriptive: The underlying connection was closed: An unexpected error occurred on a send.

PowerCLI Error
PowerCLI Error

Fortunately, it is possible to force PowerCLI to use TLS 1.1/1.2 by editing Windows Registry as described in the KB article: Enabling the TLSv1.1 and TLSv1.2 protocols for PowerCLI (2137109).

 

 

 

Advertisements

12 thoughts on “PowerCLI Stops Working After NSX 6.2.4 Upgrade

    1. Ok the something is wrong on my side. I noticed that I did not have presistent set to source ip for https, perhaps that is the issue ?

      1. Do you have active passive two node vRO cluster? LB algorithm and persistence then does not matter as there is always one active instance. The pool should show one node as active and the other down. Healthcheck type: https, expected: 200, method: GET, URL: /vco/api/healthstatus, receive: RUNNING.

      2. So I have the load balancer in front of two vcd cells not vro. The issue I see is that with load balancer i cannot for example add the vcd host connection in vro, it says invalid credentials. The ssl cert is imported and public API addresses set correctly in vcd. Right now I have a single cell with same cert and hostname as the load balancer and all works good. With the load balancer the vcd API in general works, for example via our own c# tools that uses the rest API. As I mentioned vcloud connector also complains about invalid credentials with load balancer. In the past I had this issue aswell but that was then related to public addresses being wrong or the cert not being accepted.

  1. Oh OK. Persistence for VCD cells is nice to have but not required – anyway if you have just one cell it is irrelevant. I would check request log on the cell if you see vRO API to login. If yes, then you do not have SSL issue but credential issue. If not then you do have SSL issue and you need to investigate why.

    1. So there seems to be something with NSX after all. I even tested with SSL passthru but same result. Looking at the request logs in the cells while adding the VCD host in Orchestrator, there is no entry at all when going thru the NSX LB – the Web GUI still works fine though and rest API works in general. When using the address of one of the cells directly instead, we have log entries in the request log but it obviously fails since the api public address dont match. Even had a support ticket open verifying that Orchestrator 7.0.1 should only use tls1.1/1.2 for outgoing connections by default so i am kinda out of ideas. Any tips on how to troubleshoot this? Greatly appreciated !

      1. So never mind me, had to disable reverse path filter. orchestrator is on the same subnet as the cells and thus failed

  2. It is me again! VCC is not working without TLS 1.0 (have a ticket open). There is a workaround though – a way to enable TLS 1.0 in the NSX 6.2.4 load balancer by creating an application rule with the script “tlsv1 enable” and using it for the https virtual server.

      1. Hi Tom, thanks for this post. I’m just curious where you found the syntax for “tlsv1 enable”. Was it from vmware support? VMware has in their documentation that load balancer application rules follow the HAproxy syntax, but these commands break from the HAproxy syntax (e.g. force-tlsv12, no-tlsv10). I’m glad they put some of these options into the NSX LB (necessary even IMO) but the lack of documentation around it is a bit frustrating. Once again thanks for your post, helped me address an issue with one of our apps breaking that was coded to use TLS 1.0 on the back end.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s