NSX-T 2.2 – Error 100 when trying to enum Firewall Rules

After upgrading to NSX-T 2.2, my environment began throwing this error in the GUI when I tried to navigate to the firewall section or any router.  In addition, the nsx-cli shell script for cleanup was failing every time with a similar firewall-rule-related error.

Searching for a bitm I stumbled onto KB 56611: Upgrading NSX-T manager from 2.1.0.0 to 2.2.0.0 reports “General Error has occurred” on Firewall’s General UI section.

Down at the bottom of the KB, it essentially states that if you’ve already upgraded to 2.2 from 2.1, you’ll have to replace a jar file in order to resolve the problem.  Oh, and you have to open a ticket to get the .jar.

So, if you run into this – and you receive the nsx-firewall-1.0.jar file – here’s the steps for resolution:

1. 1. SSH into the NSX Manager as root (not admin)
   2. Navigate to /opt/vmare/proton-tomcat/webapps/nsxapi/WEB-INF/lib
   3. Copy the existing nsx-firewall-1.0.jar file elsewhere (I copied it to home and SCP’d it out from there)
   4. Copy the new nsx-firewall-1.0.jar file into this folder. (I put it on an local webserver and pulled it down with wget)
   5. Change the owner of the jar to uproton:
      

      chown uproton:uproton nsx-firewall-1.0.jar

   6. Change the permissions to match the other files:
      

      chmod o-r nsx-firewall-1.0.jar

   7. Reboot the NSX Manager
   8. Enjoy being able to see and edit firewall rules again!

 

Use Cisco Nexus 1000V for virtual hosts in nested ESXi

The native VMware vSwitch and Distributed vSwitch do not use MAC-learning. This was removed because the vSwitches would be aware of the VMs attached to them and the MAC addresses in use. As a result, if you nest ESXi under a standard vSwitch and power-on VMs under the nested instance, those VMs will be unable to communicate because their MACs are masked by the virtual host and the vSwitch is not aware of them.

Workaround options:

1. Enable Promiscuous mode on the vSwitch.
2. This works but should never be used in production.  It adds a lot of unnecessary traffic and work to the physical NICs.  It makes troubleshooting difficult and is a security risk
3. Attach your virtual hosts to a Cisco Nexus 1000V.
4. The 1000V retains MAC-learning, so VMs on nested virtual ESXi hosts can successfully communicate because the switch learns the nested MAC addresses.
5. If your physical servers support virtual interfaces, you can create additional “physical” interfaces and pass them through to the virtual instances.  This allows you to place the virtual hosts on the same switch as the physical hosts if you choose.  There is obviously a finite amount of virtual interfaces you can create in the service profile, but I think this is a clean, low-overhead solution for environments using Cisco UCS or HP C7000 or similar.

Conclusion

The Nexus 1000V brings back important functionality for nested ESXi environments, especially those environments that do not have access to features like virtual interfaces and service profiles.

Helpful links:

Standing Up The Cisco Nexus 1000v In Less Than 10 Minutes by Kendrick Coleman

VMware Horizon View Network Ports Illustrated pt. 2

As Carl pointed out, I left HTML Access (aka Blast) off of the first round of View network port diagrams.  So after going through the documents and making various connections while running TCPView, here’s the updated diagrams including the networks ports used by HTML Access and the Blast Secure Gateway.

Here’s the PDF

HTML Access & Blast Secure Gateway without Security Server

HTML Access Direct Connect without Security Server

HTML Access & Blast Secure Gateway with Security Server

Eww, curved, intersecting lines.

Once again, here’s the PDF

VMware Horizon View Network Ports Illustrated

I’ve recently had to attempt to describe the ports used in the various connection scenarios used by VMware View and found that a diagram really helped clear things up and have aided in producing accurate firewall rules.

A couple notes about the connections depicted though;

• I only included v5.x. Previous versions behave differently, so use caution if you reference these in an environment where v4.x components are reused.
• I did not depict the connection from the vCenter Server to hosts, LDAP etc. These diagrams are View-centric
• Although the View client may connect to the View Connection Server over HTTP/TCP80, I did not depict it because we strongly prefer the HTTPS, encrypted connection.
• Wyse MMR is not included since it is not supported on Windows 7 Virtual Desktops
• Black arrows indicate TCP connection request and direction
• Green arrows represent UDP traffic flow

Here’s the PDF

PCoIP with Secure Gateway on Security Server

PCoIP with Secure Gateway on Connection Server

RDP with Secure Tunnel on Connection Server

RDP with Secure Tunnel on Security Server

RDP Direct Connection without Security Server

PCoIP Direct Connection without Security Server

Once again, here’s the PDF