VPCs in VCF 9.1: what changed, and what it means for your firewall rules
VCF 9.1 gives VPCs multiple transit gateways, stateful services without NSX Edges, VLAN-backed subnets and firewall-free isolation between VPCs. Here is how the model fits together and where it changes what your physical firewall sees.
Virtual Private Clouds arrived in VCF 9.0 as the new way to consume NSX networking: tenants get self-service networks without touching the physical fabric. VCF 9.1 fills in most of the gaps that made architects hesitate. This post walks through the model, the 9.1 changes, and the questions to answer before your firewall team sees the first VPC flow.
The model in one picture
VPC networking splits responsibility between two roles.
| Role | Owns | Sees the physical network? |
|---|---|---|
| Provider (Enterprise Admin) | External connections to the physical network, IP blocks, Tier-0 gateways | Yes |
| Tenant (Project and VPC Admin) | Transit gateways, VPC gateways and subnets | No |
The building blocks, from the outside in:
- External connection: the provider's abstracted path to the physical network. It can be centralized (through NSX Edges and a Tier-0) or distributed (VLAN, and in 9.1 also VXLAN, straight from the ESX hosts).
- Transit gateway (TGW): connects a tenant's VPCs to each other and to external connections.
- VPC: the tenant's own network boundary, with its gateway and subnets.
- Subnets: where workloads live.
Subnet types decide where traffic can go
| Subnet type | Reaches | Address seen outside the project |
|---|---|---|
| Public | Data centre and internet directly | The workload's own IP |
| Private (TGW) | Other subnets on the same transit gateway | Source NAT to an external IP block when leaving, unless Private IP Blocks are enabled (9.1) |
| VLAN-backed (new in 9.1) | Attached straight to a physical VLAN, like a distributed port group | The workload's own IP |
Centralized or distributed transit gateway
This is the first design decision, and it decides where north-south traffic leaves the virtual network.
| Centralized TGW | Distributed TGW | |
|---|---|---|
| Where it runs | NSX Edge nodes, with a Tier-0 | On the ESX hosts |
| Edge cluster needed | Yes | No |
| Physical handoff | Edge uplinks | VLAN (or EVPN-VXLAN in 9.1) from every host in the span |
| Stateful services | On the Edges | In 9.1, a Virtual Network Appliance (VNA) cluster adds NAT, DHCP and load balancing |
In 9.0 the distributed model had no automatic source NAT, so a design that needed NAT pointed towards the centralized model. The 9.1 VNA removes most of that trade-off: only traffic that needs a stateful service is redirected to the appliance.
What is new in VCF 9.1
- Several transit gateways per tenant. 9.0 allowed one, which forced one topology. In 9.1 a tenant can mix centralized and distributed.
- Several external connections per transit gateway. A Remote Networks field steers traffic, for example a specific data centre range through one connection and a default route through another.
- Private IP Blocks. The provider can let private TGW subnets keep their native addresses towards the data centre, with no SNAT. Internet-bound traffic is still translated.
- Provider-managed outbound SNAT. The provider defines the SNAT pools centrally, so any transit gateway can reach shared services whatever the tenant configured.
- VLAN-backed VPC subnets for workloads that need plain Layer 2 adjacency.
- VPC span control. Limit a VPC to specific clusters, or stretch it across all vCenters in the networking domain.
- Connectivity policy between VPCs, covered next.
- Centralized TGW improvements. Active-active Tier-0 with up to eight Edge nodes, and VPN within the transit gateway.
Isolating VPCs without firewall rules
Before 9.1, stopping one VPC talking to another meant the vDefend firewall add-on. 9.1 adds connectivity policy, modelled on private VLANs, which sets routing boundaries instead:
| Policy | Can reach |
|---|---|
| Community | Other VPCs in the same community, plus promiscuous VPCs |
| Promiscuous | Every VPC in the project |
| Isolated | Promiscuous VPCs only |
A common pattern is a shared services VPC (DNS, Active Directory, logging) set to promiscuous, application VPCs set to isolated, and VPCs that genuinely need to talk grouped into a community.
What this means for your firewall rules
These are the questions we now ask on every VPC design review, because each one changes what the physical firewall sees.
- Which address will the firewall see? If a private subnet is source-NATed, the physical firewall sees the SNAT pool, not the workload. Write rules against the SNAT block, and document which tenant owns which pool. With 9.1 Private IP Blocks enabled, the native subnet appears instead, so the rules must change with that switch.
- Where does traffic leave the virtual network? With a centralized TGW it leaves through the Edge uplinks. With a distributed TGW it leaves from every host in the VPC span on the external VLAN, so the upstream gateway for that VLAN is where policy applies.
- Is east-west between VPCs open? By default it is. Decide whether connectivity policy, distributed firewall rules or both enforce separation, and record why.
- Which external connection carries which flow? With several connections per transit gateway, the Remote Networks entries decide the path. A flow allowed on one firewall can quietly move to another path when a route is added.
- Who owns the change? Tenants can now create subnets and gateways themselves. Agree up front which ranges the firewall team pre-approves, so self-service does not stall at the change board.
Sources
- Transit Gateway connectivity options in VCF 9.1 (VMware Cloud Foundation blog)
- VCF Networking 9.1: simpler VPC connectivity control (VMware Cloud Foundation blog)
- Simplify workload connectivity and enhance network scale and performance with VCF 9.1 (VMware Cloud Foundation blog)
- VMware Cloud Foundation 9.1 adds transit gateway flexibility, segmentation and native EVPN-VXLAN support (Network World)
- VCF 9 NSX VPC part 2: distributed transit gateway (evoila)
Planning firewall rules for the VCF management components behind all this? Start with the VCF Firewall Planner.