Lab N4: VPC (Virtual Private Cloud) Construct in VCF 9.0

Configure IP address blocks for VPC allocation. NSX Manager → Networking → IP Address Management → IP Address Pools → Add IP Pool. Create: Name='vpc-ip-block', Type=IP Block, CIDR=172.16.0.0/16. This block is the supernet from which VPC subnets are allocated. Also create an external IP pool for SNAT/DNAT: Name='vpc-external-pool', Range=192.168.200.100-192.168.200.200 (on the T0 uplink subnet).

Create a Project. NSX Manager → Inventory → Projects → Add Project. Configure: Name='Project-TeamAlpha', Description='Development team Alpha — self-service networking'. Assign resources: T0 Gateway='T0-Lab' (from Lab net-virt-02), Edge Cluster='edge-cluster-01', IP Blocks='vpc-ip-block', External IP Pools='vpc-external-pool'. Assign users/roles: add a tenant admin user (e.g., 'tenant-alpha-admin') with 'Project Admin' role — this user can create VPCs within the project but cannot modify infrastructure-level objects.

Create a VPC (as infrastructure admin or project admin). Within the Project context (switch to Project-TeamAlpha in the UI header), navigate to VPCs → Add VPC. Configure: Name='vpc-dev-01', Connected T0=inherits from Project, Subnets → Add Subnet: Name='subnet-web' CIDR=172.16.1.0/24 (auto-allocated from IP block), Type=Public (externally routable via NAT); Add Subnet: Name='subnet-db' CIDR=172.16.2.0/24, Type=Private (internal only, no external access). Enable DHCP for both subnets.

Verify VPC backing objects. Switch back to the infrastructure admin view. Navigate to Networking → Tier-1 Gateways — a system-generated T1 appears with a name like 'proj-TeamAlpha-vpc-dev-01-t1'. This T1 is automatically created and linked to the T0 when the VPC is created. Navigate to Segments — system-generated segments for each subnet appear. These backing objects are managed by NSX and should NOT be modified directly — all changes go through the VPC abstraction.

Deploy workloads into VPC subnets. In vSphere Client, create or move VMs to VPC subnets: Edit VM → Network Adapter → select the segment backing 'subnet-web' (it appears with a VPC-prefixed name). The VM receives an IP via DHCP from the VPC's built-in DHCP service. Deploy: vm-web-vpc (on subnet-web, gets 172.16.1.x), vm-db-vpc (on subnet-db, gets 172.16.2.x). Verify: both VMs get IPs via DHCP and can ping each other (east-west within VPC is allowed by default).

Configure VPC NAT for external access. In the VPC context → NAT Rules → Add SNAT Rule: Source=subnet-web (172.16.1.0/24), Translated IP=<IP from external pool> (e.g., 192.168.200.101). This enables web-tier VMs to reach external networks. Add DNAT Rule: Destination=192.168.200.101:80, Translated IP=172.16.1.11:80 — this maps external inbound traffic to the web VM. Verify: from vm-web-vpc, curl an external website — traffic exits via SNAT through the T0.

Apply VPC-level security policies. In the VPC context → Security → Security Policies → Add Policy. Name='vpc-dev-01-security'. Add rules: (1) 'Web-Ingress': Source=Any, Dest=subnet-web, Service=HTTP(80)/HTTPS(443), Action=Allow; (2) 'Web-to-DB': Source=subnet-web, Dest=subnet-db, Service=MySQL(3306), Action=Allow; (3) 'Deny-Direct-DB': Source=Any (external), Dest=subnet-db, Service=Any, Action=Drop. These VPC-scoped rules are isolated from other VPCs and from infrastructure-level DFW policies. The tenant admin can manage them without infrastructure admin involvement.

Compare VPC security with traditional DFW. Key differences: (a) VPC policies are scoped to the VPC — they cannot affect VMs outside the VPC; (b) Infrastructure DFW policies (from Lab net-virt-03) take precedence over VPC policies — infrastructure admin maintains override capability; (c) VPC policies use simplified constructs (subnets as source/dest, not tags/groups) — easier for tenant admins but less granular. Verify: check NSX Manager → Security → DFW — VPC policies appear in a separate section from infrastructure policies.

Test tenant isolation between VPCs. Create a second VPC in the same Project: 'vpc-staging-01' with subnet 172.16.10.0/24. Deploy a VM (vm-staging) on this subnet. Attempt to ping from vm-staging (172.16.10.x) to vm-web-vpc (172.16.1.x) — this should FAIL. Each VPC has its own routing context (separate T1 gateway) — there is no implicit connectivity between VPCs. To enable inter-VPC communication, an explicit route or peering must be configured through the T0, similar to VPC peering in public clouds.

VCF Automation integration (optional). In VCF Automation (formerly vRealize Automation), create a Cloud Template that provisions a VPC: (a) Add a Cloud.NSX.VPC resource with desired subnets and security policies defined as infrastructure-as-code (YAML); (b) Publish to the service catalog; (c) Tenant user requests a VPC from the catalog — VCF Automation creates the VPC, subnets, NAT rules, and security policies automatically. This is the Day 0 self-service model: tenants get isolated network environments on demand without opening tickets to the network team.