An NSX Project is a self-contained namespace for a tenant, business unit, or environment. Within a project, administrators can define and operate networking and security objects—completely isolated from others.
In most real deployments, a shared Tier-0 gateway anchors north–south traffic. Each project then defines its own Tier-1, which connects upward to the shared Tier-0 while maintaining strict boundaries for east–west isolation.
Each project has its own:
- Tier-1 Gateways
- Segments and NAT configurations
- DHCP and DNS settings
- Distributed Firewall (DFW) policies
- Security groups and context profiles
- Role-based access control (RBAC)
Enterprise Admins retain global visibility and control, but Project Admins—like our examples below—are confined to their own environments.
Example: Engineering vs. Sales Projects
Let’s say your organization runs two key business units: Engineering and Sales.
Historically, both teams might have shared a single NSX instance, with firewall rules and segments differentiated only by prefixes (ENG_, SALES_)
With NSX Projects, we can finally give each team its own logical sandbox.
Sales Project
Step1 – Login to NSX Mgr and define a new project as Sales. Ensure to add log identifier as Sales so it becomes easier to identify it in logs later.
- Tier-1 Gateway:
T1-SALES - Segments:
SALES-CRM,SALES-PORTAL,SALES-DB - NAT Rules: Customer portal access controlled via project-specific NAT if required
- DFW Policies: Strict separation from Engineering workloads
Create one for engineering as well
Assign users to each projects and that comes under the NSX user mgmt section. Project Admin: salesadm for sales and Project Admin: enggadm for engineering.
Create few segments under each project
As an enterprise admin, we can see both our projects being listed.
As we login as the project adm of each project we can just see only what that project is entitled to use so each project admin (enggadm, salesadm) can:
- Create and manage their own segments
- Apply security policies scoped to their project
- View logs and flows only for their own resources
- Operate independently—without risk of breaking another team’s environment
All of this while the Enterprise Admin retains centralized governance over shared Tier-0 connectivity, edge nodes, and global routing.
Before NSX 4.2, multi-tenancy:
- Before NSX Projects, achieving tenant separation meant bending the platform beyond its design intent:
- Single Shared Tier-0 Gateway: Most environments used one Tier-0 for all tenants, with routing and uplinks shared across the board. This kept the design efficient but made isolation purely logical, not enforced.
- Tier-0 VRFs: A partial step forward—each VRF gave a separate routing table and NAT space, but global objects and RBAC scope were still shared.
- RBAC Workarounds: Custom roles could hide some objects, yet true operational independence wasn’t possible.