NSX Distributed Firewall Sections and Rules via APIs

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.

  1. 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.
    etag
    Location URL will be used when we’ll modify the created Section (rename it or create/modify Firewall rules under it).

  2. 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.
    TestSectionRenamed
    The new Etag is in the Response Header.
    newEtag

  3. 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.
    Location

  4. 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:
    Rename-rule

    The new Etag to be used is in the Response Header:
    Last_Etag

    If you try to modify the FW rule using the wrong Etag, you get the following error:
    Error_wrong_Etag

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

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.