Reading Time: 5 minutes

As the holiday season is almost upon us (just two days), why not finish with one final article in my vRNI series and an article that will likely finalise my blog posts for the year.

In my previous article (VMware vRealize Network Insight (vRNI) – Part 5 – Data Flow Analysis & Micro-Segmentation), we analysed collected data flows in vRNI to manually micro-segment an application utilising the VMware NSX-T Distributed Firewall (DFW). However, what if we want to automate this process? After all, applications that require a small number of firewall rules (such as the application used in the previous article) are rare.

This article looks at Martijn Smit‘s great script, which imports vRNI recommended firewall rules into VMware NSX-T Data Center via a Python script.

Full vRNI Series

By default, the imported rules will be in a disabled state, unless you opt to pass the –enablerules parameter when running the script. As a result, network traffic will not be impacted until you start enabling the firewall rules.

Note – While NSX-T security groups will be created based on the tier names defined within the vRNI application, this script will not populate the security groups with the respective VM or IP address members. For rules to apply to the appropriate source and destination objects, security group memberships should be populated.


  • Python 3.7 or above
  • Requests, json, argparse, sys, requests, glob, os, xml.dom, xml.etree.Elementtree, getpass python libraries installed (see requests.txt for further details)
  • Connectivity to the internet from where the script will be executed
  • Connectivity to NSX-T Manager or VIP over HTTPS (443)

Step 1 – Download the Script

Firstly, we’ll need to download the script and all accompanying files via GitHub. Simply visit and grab all the files.

Step 2 – Install Python

This article assumes you have already installed Python and it’s required modules, details for which are defined in the requirements.txt downloaded in conjunction with the above script.

If you are yet to install Python, install the relevant release (see prerequisites above) and, as I’m using a Windows desktop, I launch a Command Prompt and install the required modules using the below commands.

py -m pip install requests
py -m pip install requests_toolbelt

Step 3 – Export vRNI Recommended Firewall Rules

In the previous article, we noted that just because traffic is observed, doesn’t mean it should be enabled. So why would we want to export all recommendations blindly? More on this later.

1. Login to vRNI and, via the search bar, enter the below criteria:

plan security of application 'Application Name'

2. From the Micro-Segments section, click the three dots and click Export Rules as XML. In our scenario, we’ll download all recommendations and review in a later step.

3. Extract the downloaded .zip file and let’s take a look at the contents. Browse to nsx-rules/universal and note the .xml files which define our firewall rules and services, as well as the .csv files which define security groups, security tags, services, etc.

Step 4 – Run the Python Script

1. Launch a Command Prompt and run the Python script. When prompted, enter the requested details to target either VMware NSX-T DFW or NSX on VMC.

py "Path-To-Python-Script" --rulefolder "Path-to-Rule-Folder" --appname "NSX-Policy-Name" --nsxturl "NSX-Manager-or-VIP-URL" --nsxtuser "NSX-Username"

Step 5 – Review and Enable NSX-T DFW Rules

1. Login to VMware NSX-T Data Center.

2. Browse to Inventory > Groups and review the security groups created by the script. Note that the security group names are appended with the text, -vRNI-Import-Tier, making searching for the automatically created groups easier. Add the respective VMs to the respective security group(s) as per the application topology.

3. Browse to Security > East West Security > Distributed Firewall and note the newly created DFW policy.

4. Expand the policy and review/validate all rules. Note that all rules are disabled as we did not use the –enablerules parameter when running the script. At this point, you have the option to edit or remove DFW rules.

5. Once you have validated the DFW rules, enable the rules and (as we are implementing micro-segmentation on a per-application basis (brownfield environment)) create inbound and outbound drop rules for all services to/from the application. Place these at the bottom of the policy and apply to all servers within the application.

6. Finally, publish the DFW rules.

In Summary

In this article, we utilised Martijn Smit’s script to import vRNI recommended firewall rules to the NSX-T DFW.

In the previous article, and as mentioned above, we noted that just because traffic is observed, doesn’t mean it is valid. As such, you can see the importance of understanding your applications, their dependencies, and firewalling requirements.

This script will help a great deal when large numbers of firewall rules are required, however, it’s important these are reviewed and validated with the respective application owners before they are enabled.

We have now covered the manual and scripted process of creating NSX-T DFW rules based on vRNI data flow analysis. One final option exists, of course, and that is NSX Intelligence. More on this to follow in 2021.


I’d like to wish you all a happy holiday season, and a huge thank you to all followers for your support and collaboration throughout this past year. Needless to say, 2020 has been a very different kind of year and, unfortunately for some, a very tough year indeed. Thank you to all readers, Xtravirt, VMware, and all within the tech community, vExpert and VMUG programs. Your support and comradery have been truly inspiring.

Further Reading/Viewing

Full vRNI Series


  1. can I import exported firewall rules from a vRNI instance that has a production NSX-T integrated and importing those rules into a lab NSX-T that basically has very minimal config using the same script? I do get errors so i’m just wondering if it’s even possible to start with

    1. Yes this should work without issue. If you are having problems it is not related to the NSX-T Instance the recommendations is for, or the instance you’re actually applying the rules towards.

    1. If you are having problems it is not related to the NSX-T Instance the recommendations is for, or the instance you’re actually applying the rules towards. There is likely something else missing thats tripping up the script from running.

Leave a Reply

Your email address will not be published.

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