When you use the vCenter virtual appliance in an environment protected by VMware NSX, there is a chance for accidentally blocking access to vCenter due to a misconfigured firewall rule. When that happens, you get into serious trouble since you also lose the GUI for configuring NSX, so you can’t undo what has gone wrong.
Luckily, there are ways of recovering from that situation and they are perfectly explained in several blogs out there, take the following two as a sample:
- NSX for vSphere: recovering from Distributed Firewall vCenter lock-out https://telecomoccasionally.wordpress.com/2014/03/08/nsx-for-vsphere-recovering-from-distributed-firewall-vcenter-lock-out/
- Create firewall rules that blocked your own VC http://www.routetocloud.com/2014/05/create-firewall-rules-that-blocked-your-own-vc/
These blogs propose a complete wipe out of your existing firewall configuration, taking it back to factory default where all traffic is allowed.
I have just happen to experience the same situation myself recently, though losing existing DFW configuration was not an option since there was plenty of time and work invested into it. So I figured out a different way to recover from the same lock-out situation by adding a new rule that allows all traffic on top of the existing configuration. The rest of this blog details the steps for that.
- From your favourite browser, access the NSX Manager URL until you get to the login screen, accepting the security warnings as required.
- From the same browser instance, launch your favourite REST API client. In my case, I used Firefox with the following add-on https://addons.mozilla.org/en-US/firefox/addon/restclient/
- Configure the following headers:
- Authentication, Basic Authentication -> NSX Manager userid and password
- Headers, Custom Header -> Content-Type: application/xml
- Issue a GET request to the following URL https://NSX-Manager-IP-Address/api/4.0/firewall/globalroot-0/config
- Take note of the Etag value on the Response Headers tab since it will be used later:
- Navigate to the Response Body (Highlight) tab and copy all its contents to your favourite text edit:
- At the beginning of the firewall config, right after the first section id available, add the new rule that will allow all traffic through, in blue below:
<?xml version="1.0" encoding="UTF-8"?> <firewallConfiguration timestamp="1464880714374"> <contextId>globalroot-0</contextId> <layer3Sections> <section id="a335b9d5-c61a-4423-83fe-7d38df7d8470" name="Cross-vCenter DFW Rules" generationNumber="1464880714374" timestamp="1464880714374" managedBy="universalroot-0" type="LAYER3"> <rule disabled="false" logged="true"> <name>Rescue Rule</name> <action>allow</action> </rule> <rule id="2147483651" disabled="false" logged="true" managedBy="universalroot-0"> <name>Web-to-Web</name> <action>deny</action> <appliedToList> <appliedTo> <name>DISTRIBUTED_FIREWALL</name> <value>DISTRIBUTED_FIREWALL</value> <type>DISTRIBUTED_FIREWALL</type> <isValid>true</isValid> </appliedTo> </appliedToList> [truncated output]
- Configure a new header on the REST API client:
- Header, Custom Header -> If-Match = Etag value from step 5
- On the REST API client change the method from GET to PUT keeping the same URL.
- Copy the edited text from step 7 and paste it into the Body field of the REST API client. Click on Send:
- If the operation is successful you will get a 200 Status Code on the Response Headers tab:
And on the Response Body (Highlight) tab you will see the ID of the just created rule, on the example below 2147483657:
- Finally, you should have gained access to vCenter again and in the NSX DFW section you will find the new rule at the top-most position:
Hope it helps!!