In the last post of this series, I discussed how to create NSX Projects and apply RBAC and Quota policies to them. I also touched base briefly on the project’s security (DFW) aspect.

In this post, I will discuss the project’s security in greater detail. 

If you are not following along, you can read the earlier parts of this series from the below links:

1: NSX Multitenancy Introduction

2: Multitenancy Design Models

3: Creating NSX Projects

One of the key purposes of the Project feature is to allow security policy management to be delegated to the project admin to avoid the danger of rules being applied to the wrong virtual machines.

When an NSX project is created by the Enterprise Admin, the system generates default Distributed & Gateway firewall rules to regulate the default behavior of east-west and north-south traffic for the VMs in the NSX project.  The firewall rules in a project apply only to the VMs created in that project and don’t impact VMs created in other projects or the default space.

You can view the DFW rules for a project by navigating to the Security > Distributed Firewall page within the project view.

By default project vms can communicate with one another without any restriction. However, you won’t be able to reach the default gateway or any other vms that doesn’t belong to this project. 

To create the firewall rules, the NSX manager creates a default security group following the naming convention “PROJECT-<project name>-default”

The project vms and the logical segments created inside the project are added as compute members to this security group.

Clicking on the Where Used button lists the DFW rules where this security group is consumed. 

Since the outbound and inbound access is blocked by default, you can implement additional firewall rules to allow the communication. 

In my lab, I added a new rule to allow access from the project vms to the physical network and limited the rule’s scope to the project’s security group. The rule ID of this rule is 1055 and we will examine this rule shortly in cli.

And I can now ping my infrastructure servers from the project VM.

Let’s examine the rule at the host level. Grab the NIC’s name using the summarize-dvfilter command

Under the pre-filter section, we see that for rule id 1055, ICMP/ICMP-v6 communication is allowed via the distributed firewall. 

As the default project security group is present in the default space, the Enterprise Administrator can create policies to govern project traffic from the default space. Rules written in the default space will take precedence over the rules set at the project level for the relevant DFW category.

To test this, I added a drop rule for the engineering project security group in the default space. The rule id for this rule is 2024

At the host level, rule id 2024 for connection drop appears before rule 1055 (rule id of projects fw rule) and hence the outbound connection will be dropped even if the communication is allowed at the project’s level.

And that’s it for this post. In the next post of this series, I will discuss  Virtual Private Clouds (VPCs) in NSX Projects. Stay tuned!!!

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.