Blog Authored by Pravin Goyal

So, you have spent a lot of time and created a master blueprint of how your network segment should look and function. You spend multiple hours and thousands of dollars on a segmentation solution to enforce your network segmentation design. You are happy, that is an achievement indeed, isn’t it?

Alright, a few days pass by, and you are informed that there is a security audit.

An auditor walks in and tells you,

“Howdy, Ms./Mr. Network Admin? Can you please run a few checks for me?”

  1. Show me that you have E-W segmentation working.
  2. Show me that you have N-S segmentation working.
  3. Show me that pings are disabled until specifically allowed.

You start flipping through the firewall and Access Control List (ACL) rule screens and rapidly scrolling thousands of rules spread between various segmentation enforcement solutions and mechanisms. Rules could be on a segmentation solution such as VMware NSX Distributed Firewall (DFW), NSX Edge Firewall, or traditional perimeter firewalls such as Palo Alto Panorama. Some rules could also be locally defined as ACLs on networking devices.

So, how do you demonstrate that the path between two entities is effectively segmented and figure out the precise segmentation rule that enforces that segmentation without jumping back and forth? That is precisely where VMware VMware Aria Operations for Networks Assurance and Verification feature can help you to demonstrate and prove adequate network segmentation. Just to remind you of the point, an effective segmentation strategy does not only mean blocking but also allowing communication explicitly as required.

Let’s drill down further and understand how to use VMware VMware Aria Operations for Networks (formerly vRealize Network Insight) to demonstrate segmentation. There are many visibility capabilities with the new dashboard in the latest 6.9 version. For this blog, I use examples with VMware NSX, Palo Alto Networks Panorama firewalls, and a Juniper switch.


Scenario 1 – Demonstrate E-W Segmentation

Assume that you have a 3-tier application consisting of

  • Web tier
  • App tier
  • Database (DB) tier

You have the following segmentation rules defined.

  • Web tier to App tier Allowed
  • App tier to Database (DB) tier Allowed
  • Web tier to Database (DB) tier Denied

Let’s roll.

VMware Aria Operations for Networks allows you to perform advanced path searches between two entities.

Figure 1. Using Path Search, you can specify a source, destination, hops, port, protocol, direction, etc., as evident in the screenshot.

But, for this scenario, let’s perform a simple path search between a Web tier VM and an App tier VM.

Figure 2. Example Path Search query between 2 different locations

As expected, the traffic between these two tiers is allowed.

Figure 3. Path results example.

The path search results show two allowed paths and four blocked paths. Let’s drill down further on the permitted path. You see a network map for the permitted path.

Figure 4. Example of network map for the permitted path.

The details provide a visible hop-by-hop detailed path along with packet headers.

Figure 5. Path 1 and Path 2 are available with forward and reverse path details along the path for the earlier query between 2 locations.

Now, if you click on the ACL link, it will show you the exact segmentation rule defined on VMware NSX that allowed the communication between Web tier and App tier.

Figure 6. Access Control List details showing segmentation rules.

Now, let’s try a path search between a VM in the Web tier and a VM in the Database tier.

Figure 7. A new path search between 2 different VMs.

As expected, the path search comes back with all blocked paths.

Figure 8. Path search shows all 6 paths are blocked.

You could expand the search results and figure out the exact segmentation rule blocking that path.

Figure 9. Looking into the Access Control List blocking the path between the source and destination.
Figure 10. Looking at the Access Control List action which shows “Drop.”

Simple and cool, isn’t it? You could very effectively demonstrate segmentation boundaries and prove that your hard work paid off!


Scenario 2 – Demonstrate N-S Segmentation

Now let’s switch gears and perform a similar exercise but this time with a North-South perimeter firewall such as Palo Alto gateway in place.

This time you do an advanced search where you specify ICMP as the protocol between 10.0.1.1 and 20.0.1.1.

Figure 11. Path search with ICMP traffic between 2 different locations.

The search result shows that ICMP is allowed between those points. Clicking on the ACL shows you the exact configuration on the Palo Alto Networks (PAN) device that allowed the ICMP communication.

Figure 12. Looking at the Palo Alto Networks firewall rule which is allowing traffic.

Now, let’s try another advanced search with the following parameters.

  • Source IP – 10.0.2.1
  • Source Port – 179
  • Destination IP – 2.2.2.2
  • Destination Port – 135
  • Protocol – TCP
Figure 13. You find that the traffic is blocked. You can check out the exact ACL entry that blocked that traffic.
Figure 14. Looking at the Palo Alto Network firewall rule details.

How helpful is that, isn’t it? I want to reiterate here that such advanced path search and precise device configuration mapping capabilities are extremely useful when troubleshooting traffic controls to get your segmentation blueprint right. It saves you a lot of time to ensure that the rules are really working as expected and yeah, not to fear audits!


Scenario 3 – Demonstrate within Data Center Traffic Control

Finally, let’s take the last scenario where you want to demonstrate that ping is disabled unless specifically allowed.

Assume that you have two Arista switches serving three subnets 10.0.1.0/24, 20.0.1.0/24, and 30.0.1.0/24. They are neighbors of a Juniper switch where you have configured local ACL entries to allow ICMP traffic between 10.0.1.0/24 and 20.0.1.0/24 but not between 10.0.1.0/24 and 30.0.1.0/24.

Now, if you do an advanced path search between 10.0.1.1 and 20.0.1.1 for ICMP protocol, you find that it is allowed.

Figure 15. Path search between 2 different locations show traffic is permitted.

As usual, you can click on the ACL entry to see the precise local ACL configuration that allows the ICMP traffic between 10.0.1.1 and 20.0.1.1.

Figure 16. From the VMware Aria Operations for Networks console, other devices can be viewed such as the Juniper configuration showing that traffic between 10.0.1.0/24 and 20.0.1.0/24 is permitted.

Now, if you do an advanced path search between 10.0.1.1 and 30.0.1.1 for ICMP protocol, you find it is blocked.

Figure 17. Path search shows that traffic is blocked between 10.0.1.1 and 30.0.1.1 at the Juniper device.

You can click on the ACL entry to see the precise local ACL configuration that denied the ICMP traffic between 10.0.1.1 and 30.0.1.1.

Figure 18. Juniper device configuration that is blocking traffic as visible from the VMware Aria Operations for Networks console.

So, as you see, VMware Aria Operations for Networks gives deep visibility of your segmented network irrespective of where the rules are configured. You can use it to demonstrate effective segmentation and troubleshoot segmentation related issues.


Conclusion

VMware Aria Operations for Networks is a seasoned networking monitoring and troubleshooting product that helps you to manage your network securely and confidently at scale with intelligent application discovery, network optimization, Kubernetes deployment visibility, analytics, and troubleshooting with Assurance and Verification across multi-vendor, multi-cloud, and SD-WAN environments. It is available as an on-premises deployment as well as SaaS. You could begin with a quick 30-day SaaS trial and realize the power it gives you to effectively manage and troubleshoot your networks!

You can also learn more about other VMware Aria Operations for Networks features on TechZone


Pravin Goyal is a Group Product Line Manager at VMware working on VMware Aria Operations for Networks (vRealize Network Insight).