Reading Time: 6 minutes

In the previous articles of this series, we covered the installation (VMware vRealize Network Insight (vRNI) – Part 1 – Installation) and configuration (VMware vRealize Network Insight (vRNI) – Part 2 – Configuration) of vRealize Network Insight, before integrating vRNI with Microsoft Active Directory via LDAP (VMware vRealize Network Insight (vRNI) – Part 3 – Identity & Access Management via LDAP).

In the most recent article (VMware vRealize Network Insight (vRNI) – Part 4 – Application Discovery), we delved into application discovery. We defined four applications via several options – manual creation of an application, as well as automated discovery based on vSphere Tags/Custom Attributes and VM naming conventions.

In this final article of the series, we will explore and analyse the collected data flows of one of the previously defined applications. The goal here is to identify all valid traffic flows required to secure the application utilising the NSX-T Distributed Firewall (DFW). My friends, today we look at micro-segmentation.

Full vRNI Series

Application, T001A003, is a simple two-tier web application, specifically, WordPress. The application consists of an Apache webserver frontend, with a MySQL server in the backend.

We can consider the NSX-T environment as a brownfield deployment. As such, the current configuration of the NSX-T DFW allows full access to/from the application in question and, in this article, we will implement micro-segmentation on a per-application basis – i.e., we will block all traffic to/from all elements of the application, then layer-on our ‘allow’ rules based on the collected vRNI data flows.

Access to our two-tier WordPress application via HTTPS (443).
ICMP traffic is also currently allowed to the web VM (T001A003-WEB-01).

Note – Remember the allowed ICMP traffic displayed above. When we have finished implementing the DFW rules, this traffic will be dropped.

Application Topology

As we defined our application in the previous article, we are able to visualise its topology by a) browsing to Plan & Assess > Applications or b) using the search bar by typing Application ‘<Application Name>’.

Browse to Plan & Assess > Applications
…or use the search bar by typing Application ‘<Application Name>’

In the below screenshot we are presented with the Application Topology. Note the inclusion of both WEB and DB tiers (configured in the previous article), as well as the individual VMs located within each tier. From here, we can visualise the traffic flows to/from the VMs easily by selecting any of the data flows.

Click any of the data flows for more information on source/destination, as well as the protocols used.

Flows for Each VM

Another way of reviewing the data flows is to scroll down to the Flows section (or by clicking the Flows tab) and by clicking either of our two VMs.

Traffic Flows

Clicking into one of the above VMs enables us to view further information for this entity. Note the search term populated in the search bar should you wish to use this in the future, rather than browsing.

VM overview, key information, topology, and path to internet.


Next, we’ll begin reviewing the collected data in readiness for securing the application via the NSX-T DFW.

Browse back to the application in question and scroll down to the Microsegmentation section (or click the Microsegmentation tab). From here, we can hover over any of the ‘donut’ segments to give us a basic representation of the data flows.

Hovering over any of the donut segments gives us a basic visual representation of the data flows.

Clicking into either of the WEB or DB segments will display more detailed traffic flow information for each application tier. By browsing to Flows (Incoming and Outgoing), we see several flows, as well as details about their source, destination, and ports utilised. That said, just because a flow is displayed, doesn’t mean it should be allowed.

Not all flows are equal. Just because a flow is shown, doesn’t mean it’s something we want to allow. Application documentation is key.

In our scenario, only the top two flows are valid:

  • Flow #1 (top) is a client web browser ( accessing the web VM (T001A003-WEB-01) on port 443.
  • Flow #2 (middle) is the webserver VM (T001A003-WEB-01) communicating with the MySQL VM (T001A003-DB-01) on port 3306.

The VM hosting the WordPress frontend is an out-of-the-box TurnKey Linux VM. Flow #3 (bottom) details communication with an external destination for NTP. This is not traffic I want to allow. As I will be implementing zero-trust for this application, we will only be adding rules for the allowed data flows. Everything else will be dropped.

Next, by clicking Recommended Firewall Rules, we can see vRNI’s recommendations. As mentioned previously, just because vRNI witnesses a data flow, doesn’t mean we want to allow it. In the below screenshots, I review the rules for both the WEB and DB application tiers.

Services and Flows for WEB – Recommended Firewall Rules for the application tier ‘WEB’.
Services and Flows for DB – Recommended Firewall Rules for the application tier ‘DB’.

From the above recommendations, we will create the following DFW rules:

  • Any source to WEB VM via TCP and UDP 443
  • WEB to DB – TCP 3306
  • All other vRNI recommendations are not seen as valid, will not be added as ‘allow’ DFW rules and, as such, will result in such traffic being dropped.

Note – Although DNS traffic has been identified in the above recommendations, I won’t be creating an application-specific rule as one already exists as an Infrastructure DFW rule.

Now that we’ve identified the valid traffic flows let’s jump over to NSX-T and create a new DFW Application Policy and rules. Once created, the policy and rules are published and, moments later, ICMP traffic is dropped while access to the application remains uninterrupted.

NSX-T Distributed Firewall Rules – per-application micro-segmentation.
After publishing the newly created DFW rules, ICMP traffic is dropped…
…whilst the application continues to run uninterrupted.

In Summary

In this article, we reviewed the collected data for a discovered vRNI application. With this data, we were able to identify valid traffic flows and define several NSX-T DFW rules. The implementation of the DFW rules then allowed us to micro-segment and secure the application whilst the application itself continued to run uninterrupted.

Of course, this was a simple, two-tier application with minimal firewall requirements. In a production environment, things might look substantially different so, in a future article, we will look at how we can utilise vRNI and NSX-T to automate the creation of DFW rules.

Until then, stay tuned, and happy micro-segmentation!

Full vRNI Series

1 Comment

  1. Hi, thanks for the great article! I have a question regarding ICMP flow in vRNI
    Does vRNI generally show the ICMP traffic ? Is there any search filter that could show this?

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.