When you have to create multiple Distributed Firewall Rules, it could be very helpful to leverage NSX APIs.
It could be even more helpful to create different DFW Sections to logically separate different Tenants.
The maximum number of sections you can create under a single NSX Manager is 10,000.
The maximum number of Firewall Rules you can create per NSX Manager is 100,000.
vCloud Director 8.20, thanks to the new NSX integration, enables the configuration of Micro-Segmentation configuration on a per Tenant, per Organization Virtual DataCenter basis.
Distributed Firewall configuration is managed in the scope of every single vDC (note: DFW must be enabled on the vDC by a System Administrator).
In NSX Manager, a different Section is created for every vDC when Distributed Firewall has been enabled.
When you want to leverage the APIs to interact with the Distributed Firewall, you must obtain the Etag for the object you need to modify.
Etag stands for Entity tag and it is an identifier for a specific version of a resource. It’s used like a fingerprint to be sure that the representation of an object is not changed since the last interaction with it.
Following some examples of API interaction with DFW Sections.
- Firewall Section Creation
POST https://NSX-MANAGER/api/4.0/firewall/globalroot-0/config/layer3sections –header ‘Content-Type:text/xml’Body
<section name=”TestSection”>
</section>
The Response Header contains Etag and Location of the new object (the DFW Section) to be used for future changes.
Location URL will be used when we’ll modify the created Section (rename it or create/modify Firewall rules under it). - Firewall Section rename (optional, it will modify the Etag)
PUT https://NSX-MANAGER/api/4.0/firewall/globalroot-0/config/layer3sections/1006 –header ‘Content-Type:text/xml’ –header ‘if-match:”1495902005576″
if-match makes the API call conditional, it’s only considered valid if the Etag passed in the call is equal to the one cached on the Server if the object has not changed in the meantime.Body
<section name=”TestSectionRenamed”>
</section>Result: the previously created Section has been renamed to TestSectionRenamed.
The new Etag is in the Response Header.
- Creation of a new Firewall rule in the created Section
POST https://NSX-MANAGER/api/4.0/firewall/globalroot-0/config/layer3sections/1006/rules –header ‘Content-Type:text/xml’ –header ‘if-match:”1495902401161″Remember to always use the last generated Etag.Body
<rule disabled=”false” logged=”true”>
<name>Test-Rule</name>
<action>ALLOW</action>
<sources excluded=”false”>
<source>
<value>10.112.1.1</value>
<type>Ipv4Address</type>
<isValid>true</isValid>
</source>
</sources>
<services>
<service>
<destinationPort>80</destinationPort>
<protocol>6</protocol>
<subProtocol>6</subProtocol>
</service>
</services>
</rule>In the Response Header you can find the Location of the new object (the Firewall Rule) and the new Etag to be used for future changes.
- Firewall Rule change
GET https://NSX-MANAGER/api/4.0/firewall/globalroot-0/config/layer3sections/1006
The Response Header contains the Etag to be used to modify the rule.
If no changes happened since last change, it will be the same you can see in the screenshot at point 3).You can modify the DFW rule with the following call, using the object Location URL obtained before.
PUT https://NSX-MANAGER/api/4.0/firewall/globalroot-0/config/layer3sections/1006/rules/1007 –header ‘Content-Type:text/xml’ –header ‘if-match:” 1495903193596″Body
<rule disabled=”false” logged=”true”>
<name>Test-Rule-Renamed</name>
<action>allow</action>
<appliedToList>
<appliedTo>
<name>DISTRIBUTED_FIREWALL</name>
<value>DISTRIBUTED_FIREWALL</value>
<type>DISTRIBUTED_FIREWALL</type>
<isValid>true</isValid>
</appliedTo>
</appliedToList>
<sources excluded=”false”>
<source>
<value>10.112.1.1</value>
<type>Ipv4Address</type>
<isValid>true</isValid>
</source>
</sources>
<services>
<service>
<isValid>true</isValid>
<destinationPort>8080</destinationPort>
<protocol>6</protocol>
<subProtocol>6</subProtocol>
<protocolName>TCP</protocolName>
</service>
</services>
<direction>inout</direction>
<packetType>any</packetType>
</rule>Here’s the modified rule:
The new Etag to be used is in the Response Header:
If you try to modify the FW rule using the wrong Etag, you get the following error:
You can find the full NSX API documentation at the following link:
https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.3/nsx_63_api.pdf
