Projects help you to isolate networking and security configurations across tenants in a single NSX deployment.

Prerequisites

You must be assigned the Enterprise Admin role.

Procedure

  1. From your browser, log in to an NSX Manager at https://nsx-manager-ip-address.
  2. Click Default, and then click Manage.
  3. Click Add Project.
  4. (Required) Enter a name for the project.
  5. Select a tier-0 or a tier-0 VRF gateway that the workloads in this project can use for north-south connectivity with the physical network outside NSX.

    You can select multiple gateways, if required. If no gateway is selected, the workloads in the project will not have north-south connectivity.

    Note: By default, the project is created in the default overlay transport zone of the system. Therefore, the tier-0/VRF gateways that are associated with the default transport zone are displayed in the drop-down menu.

    A tier-0 or a tier-0 VRF gateway can be assigned to multiple projects. That is, allocating a tier-0/VRF gateway to one project (say project 1) does not prevent you from allocating it to other projects (say project 2 and project 3).

  6. Select an edge cluster to associate with this project.

    The selected edge clusters can be consumed inside the project in the future. For example, the edge clusters can be consumed for running centralized services such as NAT, Gateway Firewall, DHCP, and so on, that you configure on the tier-1 gateways inside the project. When you add NSX VPCs in the project, the same edge clusters are consumed for providing centralized services to the workloads in the VPCs.

    The project can be associated with the same edge clusters, which are used by the tier-0/tier-0 VRF gateway that is assigned to the project. If required, you can associate separate edge clusters to the project and the tier-0/tier-0 VRF gateway. An edge cluster can be assigned to multiple projects. That is, allocating an edge cluster to one project (say project 1) does not prevent you from allocating it to other projects (say project 2 and project 3).

    Note: The edge clusters that are associated with the default overlay transport zone are displayed in the drop-down menu.
  7. In the External IPv4 Blocks field, select one or more existing IPv4 blocks.

    The selected IPv4 blocks will become available to you when you add public subnets in the NSX VPCs within the project. The system will assign CIDR blocks to the public subnets in the NSX VPCs from these external IPv4 blocks. VPC users can also use the external IP blocks for adding NAT rules in the NSX VPCs.

    If no IPv4 blocks are available for selection, click Actions menu, and then click Create New to add an IP address block.

    The external IPv4 blocks must not overlap each other within a project, and they must not overlap on the same tier-0 gateway.

    For example, let us assume that project A is connected to tier-0 gateway A, project B is connected to tier-0 gateway B, and the tier-0 gateways of these two projects are isolated. In this case, projects A and B can use the same or overlapping external IP blocks because they are connected to separate tier-0 gateways.

  8. In the Short log identifier text box, enter a string that the system can use to identify the logs that are generated in the context of this project.

    The short log identifier is applied to the security logs and audit logs.

    If you have dedicated a tier-0/VRF gateway to a project by configuring the dedicated_resources parameter in the project API, the short log identifier is appended to the log messages that are generated in the edge syslog for the centralized services, which are running on the tier-0/VRF gateway. To learn more, see Enabling Project Context in NSX Edge Syslog.

    The identifier must be unique across all the projects in your NSX environment.

    The identifier must not exceed eight alphanumeric characters. If it is not specified, the system autogenerates it when you save the project. After the identifier is set, you cannot modify it.

  9. Use the Activate Default Distributed Firewall Rules toggle to turn on or turn off the default distributed firewall rules for this project.

    The default DFW rules allow communication between workload VMs within the project, including communication with the DHCP server. All other communication is blocked.

    This toggle is editable only when you apply an appropriate security license in your NSX deployment that entitles the system to the distributed firewall security feature.. This setting only turns on/off the default distributed firewall rules for the project. It does not turn off the distributed firewall in the project.

    For instance, if distributed firewall service is activated in your NSX platform, you can still deactivate the default firewall rules of the project. In this case, the system-wide default distributed firewall rules that are configured in the default space will be applied to the project.

    The following table explains the default state of the Activate Default Distributed Firewall Rules toggle in the project under various scenarios. The term "base license" that is used in this table refers to any of the following two licenses:

    • NSX Networking for VMware Cloud Foundation
    • Solution License for VCF
    Sr. No. Scenario Default State of the Toggle Notes

    1

    You are a new NSX customer and have applied a base license that entitles the system to only the NSX networking features.

    Off

    This toggle is not editable because the current applied license does not support configuration of distributed firewall security rules.

    You need to apply the appropriate security license in the system, and then turn on this toggle to activate the default distributed firewall rules in the project.

    2

    You are a new NSX customer. On day 0, you have applied a base license that entitles the system to NSX networking features. You have also applied an appropriate security license that entitles the system to distributed firewall security.

    On

    The default distributed firewall rules are activated for the project.

    You can turn it off in the project, if required.

    3

    You are a new NSX customer. On day 0, you applied only the base license that entitles the system to only the NSX networking features. You have added some projects in the system, let us say, projects A and B

    Later, during day 2 operations, you applied an appropriate security license that entitles the system to distributed firewall security.

    Now, you added user-defined distributed firewall rules in the existing projects A and B, and also created new projects in the system, let us say, projects C and D.

    Off: for pre-existing projects in the system

    On: for new projects in the system

    In this scenario, the term "pre-existing projects" refers to projects that existed in the system before the security license was applied on day 2. In this scenario, they refer to projects A and B. The term "new projects" refers to projects that are added in the system after the security license was applied on day 2. In this scenario, they refer to projects C and D.

    For pre-existing projects A and B, the system behavior is as follows:

    This toggle will be in the Off state, by default. The user-defined DFW rules are effective in projects A and B. If you want to activate the default distributed firewall rules in these projects, open these projects in the edit mode, and turn on this toggle manually. However, when turned on, it might impact the behavior of east-west traffic in projects A and B.

    For new projects C and D, the system behavior is as follows:

    This toggle will be in the On state by default. That is, for projects C and D, the default distributed firewall rules are activated, by default. If required, you can turn it off so that only the user-defined distributed firewall rules are effective in these projects.

    4

    You are an existing NSX customer with a legacy NSX license that entitles your system to a full DFW access.

    After the legacy license expires, you applied a base license that entitles your system to NSX networking features, and also applied a security license that entitles your system to distributed firewall security.

    On

    The default distributed firewall rules and user-defined distributed firewall rules continue to run in existing projects that you created before changing to the new license. There is no change in the system behavior.

    For all new projects that you add after changing the license, this toggle is turned on, by default. You can optionally turn it off, if required.

    5

    You are an existing NSX customer with a legacy NSX license that entitles your system to a full DFW access. You have added two projects in the system, let us say, projects A and B.

    After the current legacy license expires, you have applied the base license that entitles your system to only the NSX networking features. The security license is not applied.

    Now, you have created two new projects in the system, let us say, projects C and D.

    On: for pre-existing projects

    Off: for new projects

    In this scenario, the term "pre-existing projects" refers to projects that were added in the system when the legacy NSX license was valid. In this scenario, they refer to projects A and B. The term "new projects" refers to projects that are added in the system after the base license was applied. In this scenario, they refer to projects C and D.

    For pre-existing projects A and B, the system behavior is as follows:

    This toggle is in the On state, by default. You can turn it off, if needed. But, this action is not reversible. That is, you cannot activate the default E-W firewall rules again in projects A and B.

    The default distributed firewall rules and user-defined distributed firewall rules continue to run in projects A and B. But, you cannot edit these rules. Neither, you can add new distributed firewall rules. But, you can delete the existing user-defined firewall rules.

    To have a full access to the distributed firewall rules, you need to apply an appropriate security license.

    For new projects C and D, the system behavior is as follows:

    This toggle is in the Off state, by default. You cannot turn it on because the current applied license does not entitle the system to the distributed firewall feature.
    6

    You are a new NSX customer and your system has entered an Evaluation mode, which is valid for 60 days.

    Off

    During the evaluation period of a new NSX deployment, the system is entitled to only the networking features. The security features are not entitled.
  10. Optionally, enter a description for the project.
  11. Click Save.