Tag Archives: vCNS

NSX Bytes: Critical Update for NSX-v and vCNS

I generally don’t post around security releases but after going through the notes on CVE-2016-2079 I thought it was important enough to dedicate a post around. Mainly because it could impact those running NSX Edge Services Gateways or vShield Edges with the SSL-VPN service enabled for clients.

Most vCloud Director based instances won’t have the SSL-VPN enabled due to it not being exposed through the vCD UI however some Service Providers may offer this as a managed service as it’s one of the strongest features of the Edge Gateways. The issue detailed in the CVE is summarized below.

VMware NSX and vCNS with SSL-VPN enabled contain a critical input validation vulnerability. This issue may allow a remote attacker to gain access to sensitive information.

In a nutshell you need to upgrade an existing version of NSX-v or vCNS to the version below. As per usual if you have the entitlements go ahead and download the updates from the links below.

  • NSX Edge: 6.2 -> 6.2.3
  • NSX Edge: 6.1 -> 6.1.7
  • vCNS Edge: 5.5 -> 5.5.4.3

NSX-v  Downloads: https://www.vmware.com/go/download-nsx-vsphere

vCNS Downloads: https://www.vmware.com/go/download-vcd-ns

References:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2079

vCD SP 8.10 New Features Part 1 – Full NSX Support

As mentioned last week VMware released vCloud Director SP 8.10 and with it a list of significant new features and improvements. In this series I’ll go through most of the new additions a little deeper and comment around their significance. As I talked about last week in my introductory post one of the major updates was full support for NSX 6.1.x and 6.2.x. This coincides with the end of support for vCloud Networking and Security which will go EOL later this year.

This move will force vCAN Service Providers to upgrade to NSX from vShield sooner rather than later and in my opinion that is a good thing even though there are additional architecture complexities to design around as well as the increased cost pressures.

NSX Edge Improvements:

Technically whats different in the vCD 8.10 SP release is that all vDC Edge Gateways are deployed as full NSX Edges whereas before if vCD initiated an Edge deployment the VSE would be deployed at the latest 5.5.x version. Shown below is a comparison of the versions from previous vCD SP builds and the new 8.10 build.

What’s different here is that there is full support NSX ESGs configured through the vCD UI however through the vCD UI you still only have access to configure the base services as shown below. If you go to the Web Client you will see that all the enhanced NSX Edge services are enabled.

One of the other benefits is that there was a lot of issues around the VIX API and VSE monitoring between the NSX Manager and the vCD Cells and Edges loosing sync and become unmanageable. NSX ESGs are monitored and maintained through a Message Bus in a host module which is a lot more stable and should remove those loss of manageability issues. While legacy VSEs are still supported it’s now suggested that all existing VSEs are upgraded to the available ESG version from the NSX Edges Menu under the Networking & Security section of the Web Client.

NSX Advanced Networking Support:

While I am unable to talk about this product in any great detail, most vCAN Service Providers know that there is a ANS product being released that will allow deeper integration between vCD and NSX that will allow vCD Tenants to fully utilize all the features of the NSX Edge Gateways…this has been prepped since the 5.6.x releases and if you right click on an edge gateway you will see a hint of what’s to come.

Official Supportability Matrix:

Below is the official supportability matrix for all vCD SP release and NSX-v…as shown below, 8.10 is good with NSX 6.2.3, 6.1.5 and 6.1.6 but not 6.1.7.

References:

Important – vCNS and NSX End of Availability and Support Notifications

For a while now we have known that vCloud Networking and Security’s days where numbered…with the release of NSX as a replacement+ product it had been communicated to current vCNS customers that an upgrade to NSX-v would be on the cards to ensure continued support and functionality. The date has now been set for the EOA of vCNS and in somewhat of a surprise to me VMware also last week announced the EOA for NSX-v 6.1.x will reach end of availability later in the year.

VMware has announced the End of Availability (“EOA”) of the VMware vCloud Networking and Security 5.5.x which will commence on September 19, 2016

VMware has announced the End of Availability (“EOA”) of the VMware NSX for vSphere 6.1.x and will commence on October 15, 2016

In both cases the VMwareKBs state that the products will continue to function. However, support will no longer be available, nor update releases or patches…so end of the day use at your own risk and don’t expect any help is the proverbial hits the fan.

The EOA and Support of NSX-v, while a surprise can be dealt with fairly easily by existing NSX-v customers. To get the most out of NSX-v in terms of the enhanced capabilities and features you should be running a version of 6.2.x and there is a new major release just around the corner (to be announced later in the year possibly). The only current caveat is upgrades from 6.1.5 to 6.2.0 are not supported…you must upgrade from 6.1.5 to NSX 6.2.1 or later to avoid a regression in functionality.

With regard to existing vCNS customers who are not Service Providers or have not gotten their hands on…let alone wrapped their heads around NSX-v this isn’t fantastic news. This Reddit post sums up some of the feeling out there in regards to the upgrade path for vCNS to NSX-v. To sum up the general feeling that I have come across…NSX-v is a lot more expensive than what vCNS was (in most cases it was part of the general vSphere/vCloud editions and bundles) and existing users of vCNS are finding it hard to justify that cost when considering the fact that some of the best NSX-v features are surplus to their requirements.

End of the day here there aren’t too many options for vCNS customers, but there is talk about VMware releasing an NSX-Lite version to satisfy the gap that exists between current customer requirements of vCNS features vs the all in nature of the NSX-v feature set…the clock is now ticking!

vCloud Director and vCNS:

Tom Fojta blogged earlier in the week that VMware have released an additional whitepaper for for vCAT SP that goes through a vCNS upgrade to NSX in vCloud Director Environments. I’ve also covered that in my vCloud Director NSX Retrofit series here.

References:

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2144733

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2144769

 

NSX Edge vs vShield Edge: Part 3 – IPsec and L2 VPN

Overview:

NSX and vShield Edges support site to site IPSec VPN between Edge instances and remote sites. Behind each remote VPN router, you can configure multiple subnets to connect to the internal network behind an Edge through IPSec tunnels. These subnets and the internal network behind the Edges must have address ranges that do not overlap. You can have a maximum of 64 tunnels across a maximum of 10 sites.

NSX Edges are also capable of L2 VPNs where you can stretch both VXLAN and VLAN across geographical sites…This allows VMs to remain on the same subnet when they are moved between sites with the IP addresses not changing. L2 VPN allows seamless migration of workloads backed by VXLAN or VLAN between physically separated locations. Specifically for Service Providers L2 VPN provides a mechanism to on-board tenants without modifying IP addresses for VM workloads.

In this post I am only going to go through IPsec VPN configuration…feel there is a whole separate post required to do L2 VPN justice. The biggest difference between an NSX and vShield Edge when looking to configure VPNs is that when you are managing a vShield Edge you will not see the options to configure L2 VPN as shown in the configuration example below.

Configuring IPsec VPN From Web Client:

Configuration Items Required:

  • Local Endpoint
  • Local Subnets
  • Peer Endpoint
  • Peer Subnets
  • Encryption Algorithm and Authentication mechanism
  • Pre Shared Key
  • Diffie-Hellman Group

Double Click on the Edge under the NSX Edge Menu Option in Networking and Security, In the VPN Tab under Configuration click on Enable next to IPsec VPN Service Status and then hit Publish Changes

To create a new Tunnel, click on + and enter in the details collected as per the items listed above.

Click ok and then Publish the Changes…from there the Status should show a green tick. Once the other side has been configured check to see that the Tunnel(s) are up by clicking on Show IPsec Statistics.

If both sides are happy you should be able to talk between the configured subnets. Shown below you see an example of a Site to Site with One Tunnel configured up…and one down.

Configuring IPsec VPN From vCloud Director UI:

For vShield Edges managed via vCloud Director, head to the vCD UI and under Administration and the Edge Gateways. Right Click on the Edge and Configure Services. Under the VPN Tab you first want to Enable VPN and Configure the Public IPs.

Enter in the Public IP as shown above and click ok.

Click on Add and enter in the details collected. For Site to Site VPNs drop down the Establish VPN to: dropdown to a remote network and configure the rest of the settings.

Once done, you should see the Enabled and Status Column with green ticks.

A nice addition to the vCD UI (sometimes the UI team gets things right) is the Peer Settings Button which shows you the bits required to configure the other end of the connection.

Enabling/Disabling/Viewing IPsec With REST API:

Below are the key API commands to configure and manage IPsec VPN.

NSX Host Preparation: Cluster Not Ready – Legacy vCNS VXLAN VIBs Installed

I came across a situation today while going through an NSX Setup and Configuration where I came across a Cluster under the Host Preparation Tab that was reporting a status of Not Ready – Resolve and listed some hosts as Ready and Not Ready…What made this strange was that this was a fresh deployment of NSX over the top of an existing vCNS Environment.

I decided to investigate at the host level and check to see why the NSX Manager thought these hosts where already prepared with the NSX Host Extensions. I SSH’ed to each host and checked to see if the NSX VIBs where present.

The Hosts marked Ready each had the esx-vxlan and esx-dvfilter-switch-security VIBs installed but not the esx-vsip VIB. The version number got me thinking about the vCNS Implementation of VXLAN and sure enough I found a preconfigured VXLAN Multicast config present by discovering an associated VXLAN, MTU and Teaming Policy set next to the Cluster on the Logical Network Preparation Tab.

My first point of call was to try to uninstall the VIBs on the Hosts and then upon reboot have NSX Manager reinstall the NSX extensions…however all that happened was the previous two VIBs got reinstalled, leaving the esx-vsip VIB still missing…Kind of unexpected…but it appears the ghosts of vCNS remained in play.

With that action failing I decided to move onto uninstalling the old VXLAN config (ensuring no Transport Zones where tied to the Cluster) which removed the references to the old vCNS VXLAN configuration…from there I hit Resolve against the Cluster in the Host Preparation Tab. The Host in the Cluster that was Not Ready had the vCNS Host Extenions installed and took the Installation Status of the Cluster to Legacy with an Option to Update or Uninstall.

Confirming that the previously Not Ready Host only had the vCNS VIBs installed I hit the Update Link and confirmed the Update. The NSX Manager then worked with vCenter DRS to uninstall and then install the updated NSX Host Extensions…along the way putting each host into Maintenance Mode and rebooting for the upgrade to take effect.

One thing I did find is that I had to repeat the process a couple of times for the Updates to go through each host in the Cluster. The process would often do one Host and then require a Retry…not ideal but it got there in the end. I SSH’ed into a couple of the hosts to ensure the right VIBs where now installed.

Biggest take away here is to double check any existing vCNS Environment for Legacy configurations of VXLAN using the old Multicast/vCD method…if not required, make sure the config is removed before the NSX Manager Upgrade.