Users in a project can create their own distributed firewall policies to secure the flow of east-west traffic within the project. The distributed firewall rules in a project do not impact the workloads outside the project.

Default DFW Rules in a Project

For each project that is added in NSX, the system creates a default DFW policy in the project. The default policy appears at the bottom of the policy list in the Application firewall category. The default policy defines the behavior for VMs within the project if no other rules are encountered.

The following naming convention is used to identify the default DFW policy in a project:

ORG-default PROJECT-<Project_Name> Default Layer 3 section

Project_Name is replaced with the actual value in your system.

For example, the following screen capture shows the default DFW policy rules in a project.


This image is described in the surrounding text.

As seen in this screen capture, the default policy is applied to DFW, and it contains the following firewall rules:

  • Rule 1017 allows IPv6-ICMP traffic.
  • Rule 1018 allows communication to the DHCPv4 client and server.
  • Rule 1019 allows communication to the DHCPv6 client and server. (Introduced in NSX 4.1.1)
  • Rule 1020 allows communication between workload VMs within the project.
  • Rule 1021 drops all other communication that does not match any of the above rules.

The default DFW policy ensures that VMs within a project can only reach other VMs in the same project, including the DHCP server. Communication with VMs outside the project is blocked. The VMs that are connected to the segments inside the project cannot ping their default gateway, by default. If such a communication is required, you must add new rules or modify existing rules in the default DFW policy.

User-created DFW Rules in a Project

The Infrastructure, Environment, and Application DFW firewall categories are supported for projects within the organization. Inside each firewall category, the DFW rules are enforced in the following order of precedence:
  1. DFW rules in the default space (highest precedence)
  2. DFW rules in the project
  3. (Starting with NSX 4.1.1): E-W firewall rules in the NSX VPCs within the project (lowest precedence)

The DFW rules in the default space can extend to a project.

Note: The DFW rules in the default space apply to every VM in the NSX deployment, including the VMs in the projects. However, you can restrict the scope of the rules in the default space by selecting the Groups option from the Applied To setting in the UI.

For instance, you can choose to apply the rules to the project default group (ORG-default-PROJECT-<Project_Name>). The project default group contains only the workload VMs of a project.

DFW rules inside a project can access the following groups:
  • Groups that are created in the project.
  • Groups that are shared with the project.

Groups that are shared with the projects can be used only in the Source or Destination fields of the firewall rules, and not in the Applied To field of the firewall rules.

(Starting with NSX 4.1.1): If NSX VPCs are added in a project, the system-created default groups in NSX VPCs can be used in the Source, Destination, and Applied To fields of the project firewall rules. However, the user-created groups in NSX VPCs cannot be used in project firewall rules.

The firewall rules in a project apply only to the VMs in the project, that is, VMs that are connected to the segments in the project. The firewall rules within a project, including the Any-Any rules that are applied to DFW, do not impact workloads outside the project.

Adding DFW Policy in a Project

The UI workflow for adding a DFW policy in a project remains the same as it currently exists for adding policies in the Default view (default space) of your NSX deployment.

The only difference is that in the UI, you must first select a project from the project switcher drop-down menu on the application bar at the top, and then navigate to Security > Distributed Firewall for adding DFW policies in that selected project.