2. Use-Case A Private-VPC Connectivity to External Networks (Translated)

Part 1 covered the six objects behind a multi-connection Centralized Transit Gateway, where each IP block comes from, and the four rules that decide a packet's source address. It also named the central problem: a VPC Connectivity Profile has exactly one Auto SNAT block. That block satisfies the authorization list of one connection, or of several connections only when they all authorize the same block, as in Part 4. Authorizing the Internet-facing range on the WAN connection to an enterprise is not the common case, so in practice one block serves one exit.

This part builds the first steady-state design that solves it. The tenant is Cairo: workloads on a Private-VPC subnet, an enterprise that accepts traffic only from a provider-assigned range. The technique is Provider Outbound SNAT on the enterprise connection. We build it in dependency order, trace both packet paths hop by hop, and verify the result.

The Requirement

Cairo runs its workloads on Private-VPC subnets. They need two exits: the Internet, and Cairo Enterprise's network (10.111.1.0/24) over the tenant's private VRF Cairo-wan-vrf. Cairo Enterprise accepts traffic only from the provider-assigned range 10.100.10.0/24 and must never see the tenant's private addressing. The tenant must not have to write NAT rules per workload, and the Internet exit must keep using the Internet-facing block.

In terms of the Part 1 rules: the profile's single Auto SNAT block is tuned for the Internet exit, and the enterprise connection has to correct the source on its own, because it does not authorize that block. Internet-facing addresses are not normally authorized over a WAN link.

Topology

Design at a glance. The address plan is the reference plan from Part 1.

Steady-State Design

The End-to-End Workflow

Provider objects first, then the tenant's edits to the objects the project created. Provider SNAT on Cairo-wan-conn can be enabled at creation or later.

Provider space

1. Create the two External IP Blocks. In the Default project, under Networking > IP Address Pools > IP Address Blocks, create Cairo-wan-block_10.100.10.0/24 and Cairo-internet-block_10.100.20.0/24. The CIDR is in the name because every later dropdown shows the name only.

2. Create the two External Connections. Under Networking > VPC Connectivity > External Connections > Add External Connection:

Cairo-wan-conn
  Type ................... Centralized
  Tier-0 Gateway ......... Cairo-wan-vrf (VRF)
  Remote Networks ........ Cairo Enterprise prefixes (10.111.1.0/24)
  External IP Blocks ..... Cairo-wan-block_10.100.10.0/24
  Provider Outbound SNAT . On
  SNAT IP Blocks ......... Cairo-wan-block_10.100.10.0/24

Cairo-internet-conn
  Type ................... Centralized
  Tier-0 Gateway ......... Internet-T0 (Tier-0)
  Remote Networks ........ 0.0.0.0/0 (default route)
  External IP Blocks ..... Cairo-internet-block_10.100.20.0/24
  Provider Outbound SNAT . Off

The SNAT IP Blocks dropdown offers only the blocks this connection authorizes, so Cairo-wan-block is the only candidate on Cairo-wan-conn.

3. Create the project. From the project drop-down, Manage > Add Project. In Set External Connections, assign both connections and choose one as the External Connection for the Default Transit Gateway. In the reference environment the project starts with one External Connection, Cairo-wan-conn, on the Transit Gateway; Cairo-internet-conn is attached in the next step. In Set External IP Blocks, assign both blocks and pre-load them into the Default VPC Connectivity Profile.

Tenant (project) space

4. Attach the second connection. Inside Tenant-Cairo, Networking > Transit Gateways > ⋮ > Edit, pick Cairo-internet-conn under External Connection (it must be one of the connections assigned to the project in step 3), save, and wait for the status to change from In Progress to Success. The gateway now has two attachments and one default route (on Cairo-internet-conn).

5. Set the profile. Under VPC > Profiles > VPC Connectivity Profile > ⋮ > Edit, confirm both blocks are listed under External IP Blocks, switch Default Outbound NAT on, and set the External IP Block for Default Outbound NAT to Cairo-internet-block.

6. Create the VPC and subnets. Cairo-vpc-01 with the Private-VPC subnet Cairo-private-vpc-subnet 192.168.10.0/29 for the workloads and the public subnet Cairo-public-subnet 10.100.10.8/29 from the enterprise-facing block. The test workload Cairo-web-01 is on the private subnet at 192.168.10.3.

What NSX Programs Automatically

No hand-written NAT rule is needed. Three things are created for you:

• On the VPC gateway: one Default Outbound NAT rule for the VPC, translating private sources to an address from Cairo-internet-block. It exists because the profile toggle is on.
• On the CTGW, scoped to Cairo-wan-conn only: a Provider SNAT rule that translates any source outside the connection's authorized blocks to an address from the SNAT IP Block Cairo-wan-block, and a No-SNAT rule for sources already inside the authorized blocks, so they are not translated twice. The No-SNAT rule ranks below any user-defined TGW SNAT rule. Both rules are created and removed with the Provider Outbound SNAT toggle. Nothing is created for Cairo-internet-conn.
• Route advertisement: the CTGW advertises prefixes from Cairo-wan-block toward Cairo-wan-vrf and prefixes from Cairo-internet-block toward Internet-T0, because each connection's External IP Blocks limit what the CTGW advertises to that gateway.

Packet Walks

Path A — to the enterprise (10.111.1.1)

Path B — to the Internet (10.1.1.1)

Verification

From the test workload, both destinations must answer:

# From Cairo-web-01 (192.168.10.3, Private-VPC subnet)
ping 10.111.1.1   # Cairo Enterprise, via Cairo-wan-conn  — expected: success
ping 10.1.1.1     # Internet, via Cairo-internet-conn     — expected: success

Check the translation count on each path, not just reachability: traffic to 10.1.1.1 is translated once, at the VPC gateway; traffic to 10.111.1.1 is translated at the VPC gateway and again at the CTGW by Provider SNAT. The enterprise sees 10.100.10.x, the Internet sees 10.100.20.x, and neither ever sees 192.168.10.3.

The two common failure states you may pass through

Two intermediate states are worth knowing. They are what a half-finished configuration looks like in production.

State 1 — only the enterprise connection is attached. With Cairo-wan-conn as the Transit Gateway's only connection there is no default route: 10.1.1.1 is unreachable. Attaching Cairo-internet-conn fixes it.

State 2 — both connections attached, Auto SNAT block set to Cairo-internet-block, Provider SNAT still off on Cairo-wan-conn. The Internet works and the enterprise breaks. Enterprise-bound packets reach the CTGW carrying 10.100.20.x, a source that Cairo-wan-conn does not authorize and never advertised to Cairo-wan-vrf. Rule 4 applies: the source is not routable through Cairo-wan-conn, and 10.111.1.1 is unreachable.

Enabling Provider Outbound SNAT with Cairo-wan-block on Cairo-wan-conn resolves State 2 and produces the steady state above.

Note: The mirror image fails too. With the Auto SNAT block set to Cairo-wan-block instead, the enterprise path would work and Internet-bound packets would leave with 10.100.10.x, which Cairo-internet-conn does not authorize. Whichever block the profile uses, the other connection needs its own correction.

The key contrast: the Auto SNAT block belongs to the profile and applies to every destination; the SNAT IP Block belongs to one connection and applies only to traffic leaving through it. A profile has exactly one Auto SNAT block, so in most cases it can be tuned for one exit only; Provider SNAT lets the other exit correct the source on its own.

Design Notes

• Traffic from the public subnet Cairo-public-subnet 10.100.10.8/29 already carries an authorized address, so on Cairo-wan-conn it matches the No-SNAT rule and passes untranslated.
• The enterprise never learns the tenant's private addressing. It sees a provider-owned range, which is often exactly what an enterprise firewall policy requires.
• The cost is the double translation on the enterprise path: per-source logging on the enterprise side maps back to a workload only through the CTGW's NAT state.
• Provider SNAT is per connection, so attaching a third connection later does not change the behaviour of the first two.

What Comes Next

Use case A hides the tenant completely behind provider-owned addresses. The price is two translations and NAT state at two points on the enterprise path. Some enterprises want the opposite: to see the real workload addresses so their firewall rules, logs and monitoring identify workloads directly. That needs the CTGW to still hold the original private address when it decides, which a Private-VPC subnet can never offer.

Part 3 moves to Alex, whose workloads sit on a Private-TGW subnet, and builds the advertisement design: the provider grants permission on the connection, the tenant adds an advertise rule, and the enterprise learns the tenant's private block as a tgws route with no NAT on the path. It then shows the alternative for the same tenant when the enterprise insists on provider-owned addresses.