ssh root@192.168.144.30  ->  [root@esx01-a:~]  vmk0  172.30.0.40
ssh root@192.168.144.32  ->  [root@esx01-b:~]  vmk0  172.30.0.40
ssh root@192.168.144.34  ->  [root@esx01-c:~]  vmk0  172.30.0.40

Same IP. Same VLAN. Same gateway. Same MAC address, as it turns out. And none of them can reach any of the others. This is the post where NSX VPCs stop being a workaround for nested labs and become genuinely better than the physical alternative.

Why identical addressing matters

If you’ve ever built training pods, cert-study labs, or per-team reproduction environments, you know the pain: every copy needs a unique address plan, so every runbook, every screenshot, every “type this exact command” has to be parameterised per pod. Students in seat 7 see different numbers from the slides. Reproductions drift from the original.

The fix is obvious and normally impossible: give every pod the same addresses. On a physical fabric that means VRFs, per-pod NAT, and a network team that stops answering your emails. In an NSX VPC it’s the default behaviour.

The mechanism: overlapping privateIPs

Each pod gets its own VPC, and every VPC declares the same private range:

apiVersion: vpc.nsx.vmware.com/v1alpha1
kind: VPC
metadata: {name: nested-vpc-a}      # then -b, then -c
spec:
  privateIPs: ["172.30.0.0/16"]      # identical in all three

A Private subnet is never advertised beyond its VPC, so NSX has no objection to three VPCs carving up the same /16. The pods aren’t “firewalled from each other” — there is simply no route between them. Isolation by construction, not by policy.

NSX’s subnet view filtered to sn-mgmt: four rows, four VPCs, one CIDR.

The trick: deterministic realization

Identical ranges aren’t enough — I want identical subnets, so the management gateway is .33 and the hosts are .40/.41 in every pod. NSX allocates subnets from privateIPs in creation order, and a fresh VPC allocates deterministically. So the topology is applied in a fixed order — trunk, mgmt, vMotion, vSAN — and every pod realizes the same map:

In the catalog blueprint that order is enforced with dependsOn between the subnet resources — the one place a declarative tool needs to be told about sequence. Skip it and two pods can come out with mgmt and vMotion swapped, which works perfectly and confuses everyone.

The door: one VIP per host

Each pod is unreachable from outside by design, so each host gets a VirtualMachineService of type LoadBalancer publishing SSH and HTTPS. The VIPs come from the org’s external block, and they’re the only addresses that differ between pods:

Which is how the opening transcript works: three VIPs, three hosts, one inside address.

Proving the isolation

Claims are cheap. The test matrix, from a VM in a fourth VPC (the org default):

ping 172.30.0.140 (own VPC)....... REACHABLE
ping 172.30.0.40  (pod space)..... unreachable
curl http://172.31.0.2/ (shared).. shared-svc repo01

Its own VPC’s 172.30.0.140: reachable. 172.30.0.40 — an address that exists in three other VPCs simultaneously: unreachable, because from here there is no such route. (The third line is the shared-services VPC, which is the next post.)

Inside each pod, east-west is normal: esx01 → esx02 vmkping passes on all three VLANs, in all three pods. And the detail I didn’t expect: the nested-ESXi appliance derives vmk0’s MAC deterministically from its config, so the three hosts share a MAC as well as an IP. Harmless — each VPC is its own L2 domain — but a nice demonstration of how complete the separation is.

What this replaces

Why this matters outside the lab

“Identical environments” sounds like a lab nicety. It’s actually one of the most requested things in enterprise IT, usually asked for in other words:

• Training at scale — every seat in the room sees the same addresses as the slides, so material is written once and never parameterised per pod.
• Per-engineer or per-team replicas of a reference environment, for development and testing that behaves exactly like the original.
• Regulatory or business-unit separation on shared infrastructure without VRF sprawl or a bespoke firewall estate — isolation is a property of the topology, which is the easiest kind to evidence to an auditor.
• Blue/green copies of an environment for change rehearsal, then cut-over or discard.

On a physical network each of these is a project. On VCF with NSX VPCs it’s a template.

Rules learned

• Overlapping privateIPs across VPCs is supported and intentional. Identical pods are a feature, not a hack.
• Fresh VPCs realize subnets deterministically in creation order — fix the order (dependsOn in a blueprint) and every pod gets the same map.
• Pods are unreachable from outside by construction; publish exactly what you mean to via LoadBalancer VIPs from the external block.
• Prove isolation from a different VPC, with a positive control (own VPC reachable) beside the negative.
• Expect duplicate MACs across pods from appliance images. It’s fine.

Previously: the LB that must exist first. Next: one WSUS for pods that can’t see each other.

Lab environment; opinions my own. Output captured live, trimmed for length, never edited for outcome.

No. There’s a third subnet access mode for exactly this, and the design it enables is hub-and-spoke with a very specific property: spokes reach the hub; the hub cannot reach the spokes; spokes never reach each other.

The three access modes

Everything in this series comes down to one field on a VPC subnet:

PrivateTGW subnets draw their addresses from a separate transit block (here 172.31.0.0/…), not from the VPC’s own privateIPs. That’s the key: the shared range can’t collide with the pods’ 172.30.0.0/16 because it comes from a different pool that all VPCs agree on.

The build

One more VPC, shared-svc, with the same ordering rules as any other (VPC → VPCAttachment → LoadBalancer → namespace), then a single subnet:

apiVersion: crd.nsx.vmware.com/v1alpha1
kind: Subnet
metadata: {name: sn-services}
spec: {accessMode: PrivateTGW, ipv4SubnetSize: 32}

It realized as 172.31.0.0/27, and a VM on it — svc-repo01, 172.31.0.2, serving HTTP — became the shared repo.

The test that matters is directional

Reachability to the service is the easy claim. From esx01 in each of the three pods (ESXi ships python3, so urllib is the test client):

pod-a esx01 -> http://172.31.0.2/   200  shared-svc repo01
pod-b esx01 -> http://172.31.0.2/   200  shared-svc repo01
pod-c esx01 -> http://172.31.0.2/   200  shared-svc repo01
default-vpc  -> http://172.31.0.2/   200  shared-svc repo01

Three pods with identical source addresses (172.30.0.40) all hit one service and all get answers. How does the reply find its way back to the right pod when three of them claim .40? Because pod traffic crosses the transit gateway SNAT’d to a per-VPC transit address. The service never sees 172.30.0.40; it sees three distinct transit IPs. Ambiguity never arises.

Now the other direction — from svc-repo01 back toward a pod:

svc-repo01 -> 172.30.0.40   unreachable
svc-repo01 -> 172.30.0.41   unreachable

Not “blocked” — unroutable. Pod subnets are Private, so they were never advertised to the transit gateway, and even if they had been, 172.30.0.40 would be ambiguous across three VPCs. The hub literally cannot initiate into a spoke. For a shared service that will one day be compromised, that’s the property you want.

What goes in the hub

Anything that’s consumed by pods and stateless about which pod is asking: WSUS/patch mirrors, OS and package repos, container registries, NTP, DNS forwarders, license servers. Domain controllers work too, with the usual caveat that identical hostnames across pods need per-pod domains or a naming scheme.

What does not go in the hub: anything that needs to reach into a pod (monitoring pollers, backup agents pulling, jump hosts). Those either live in the pod, or the pod publishes a LoadBalancer VIP for them — the deliberate door from part 0.

Tightening further

The transit gateway gives you reachability; policy gives you precision. A VPCGatewayFirewallPolicy on shared-svc can restrict inbound to tcp/80,443 from the transit range and nothing else, so the repo is a repo and not a foothold. I left it open for the test; you shouldn’t.

Why this matters outside the lab

This is the pattern that makes isolated tenants affordable. Without it, every isolated environment needs its own patch server, repository, DNS and directory — cost and drift that quietly kill the idea. With it, a customer runs one set of shared services for dozens of tenants, keeps them patched in one place, and can still show a security reviewer that the shared service has no path back into any tenant.

The same hub serves well beyond patching: central logging and monitoring collectors, licence servers, artifact registries, build agents — anything tenants consume but shouldn’t be able to be reached by.

Rules learned

• PrivateTGW is the shared-services mode: addresses from the transit block, advertised to every attached VPC, no collision with pod space.
• Access is one-way by construction: pods → service works (SNAT’d per VPC), service → pod has no route. Test both directions and write down both results.
• Identical pod addressing and shared services coexist because of the SNAT — the hub sees per-VPC transit addresses, never the overlapping private ones.
• Same ordering rules apply to the hub VPC (VPC → attachment → LB → namespace → subnets → wait for image sync → workloads).
• Add a gateway firewall policy on the hub. Reachability is not authorisation.

Previously: three datacenters, one IP plan. Next: the whole pod as a single catalog item.

Lab environment; opinions my own. Output captured live, trimmed for length, never edited for outcome.