VMware NSX Microsegmentation – Securing Collapsed Architectures

VMware NSX Microsegmentation – Securing Collapsed Architectures

As depicted in above topology, NSX-V Distributed Firewall feature is enabled.
And as shown in figure above, firewall is effectively applied at each vNic of virtual machine.

In this topology:

  1. BGP is used as routing protocol
  2. iBGP is used within NSX
  3. eBGP is used between NSX edges and the physical ToR switches
  4. Physical switches are Juniper QFX Virtual Chassis.
  5. ToRs are advertising a default route towards NSX edges only. NSX domain uses this default route for egress traffic from the NSX domain.

A different logical switch is used for each of the three tiers viz. Web, App and Database.

In this post, we are going to showcase a key ability of NSX whereby it can impose a zero trust model and secure VMs from different tiers on the same logical switch. We are not creating a logical switch per tier in such a topology.
This new topology is as shown below.

Notice, there is a single logical switch to which Web, App and DB VMs are connected.

We will leverage Vrealize Network Insight to plan security here.

VMware vcenter server and VMware NSX manager both are added as data sources in Vrealize Network Insight.

Using the information presented to us by Vrealize Network Insight, we will populate rules on our NSX Distributed Firewall.

The IP addresses of the VMs connected to the logical switch are:
Web –
App –
DB –

Using flow queries on Vrealize Network Insight, we are able to fetch information related to destination ports.

Next, we are going to create security groups using dynamic membership criteria.
This is to showcase the ability of NSX to create dynamic security groups based on VM names.

In future, if they add more virtual machines with VM name as hr-web-02, then such a virtual machine will automatically be a part of the security group based on dynamic membership criteria as defined above.

We then define the rules on NSX Distributed Firewall.

Here, we are making sure that only required communication is allowed on the distributed firewall and everything else is blocked.
This can be seen by the default rule in pic above which is set to Block

We then verify that our rules are working as intended:

Ping from Web to App fails

We are able to connect to the web server and even though the three virtual machines belong to the same logical switch / subnet, the web server is unable to ping other machines on the same logical switch.
Effectively this is a zero trust model.

Further verification commands have been executed on Web and App VMs to illustrate that firewall rules are effective allowing only what is required and denying everything else.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s