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 18.104.22.168 to 22.214.171.124 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:
SSH into the NSX Manager as root (not admin)
Navigate to /opt/vmare/proton-tomcat/webapps/nsxapi/WEB-INF/lib
Copy the existing nsx-firewall-1.0.jar file elsewhere (I copied it to home and SCP’d it out from there)
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)
Change the owner of the jar to uproton:
chown uproton:uproton nsx-firewall-1.0.jar
Change the permissions to match the other files:
chmod o-r nsx-firewall-1.0.jar
Reboot the NSX Manager
Enjoy being able to see and edit firewall rules again!
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.
Enable Promiscuous mode on the vSwitch.
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
Attach your virtual hosts to a Cisco Nexus 1000V.
The 1000V retains MAC-learning, so VMs on nested virtual ESXi hosts can successfully communicate because the switch learns the nested MAC addresses.
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.
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.
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.
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.