> ## Content Index > Fetch the complete content index at: https://msaad.pikapod.net/llms.txt > Use this file to discover other available public pages before exploring further. # 3. Use-Case B&C Private-TGW Connectivity to External Networks (Routed or Translated) - URL: https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-3-private-tgw-advertisement-provider-snat/ - Published: 2026-09-12T13:33:42.000Z - Updated: 2026-09-13T14:48:46.000Z - Description: A Private-TGW subnet reaches the CTGW with its private address intact. That allows a design a Private-VPC subnet can never support: advertise the block to the enterprise and remove NAT from the path. Part 3 builds that design, then its Provider SNAT alternative for the same tenant. - Author: Mohammad Saad - Tags: VCF 9.1, NSX, Transit Gateway, Route Advertisement, Provider SNAT, Series: CTGW External Connectivity **Series: [CTGW External Connectivity in VCF 9.1](https://msaad.pikapod.net/ctgw-external-connectivity-vcf-9-1/)** — Part 3 of 5 [Intro: Tenant Topology for Cloud Providers running VCF9.1](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-introduction/) · [1\. Architecture and Foundations](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-1-architecture-foundations/) · [2\. Use-Case A Private-VPC Connectivity to External Networks (Translated)](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-2-provider-snat-private-vpc/) · **3\. Use-Case B&C Private-TGW Connectivity to External Networks (Routed or Translated)** · [4\. Use-Case D One Tenant, Three Exits](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-4-one-tenant-three-exits/) · [5\. Operating the Designs](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-5-operating-the-designs/) This part builds the second steady-state design, in two variants. The tenant is Alex: workloads on a **Private-TGW** subnet, showing its connectivity to the enterprise over WAN, which either routes the tenant's private range as is (use case B, the block is advertised, no NAT on the path) or accepts traffic only from a provider-assigned range (use case C, Provider Outbound SNAT on the enterprise connection), and to the Internet, which accepts only the public IP address. Both designs share one tenant, one topology and one address plan; only the settings of the enterprise connection differ between them. ## The Requirement Alex runs its workloads on Private-TGW subnets. They need two exits: the Internet, and Alex Enterprise's network (`10.111.2.0/24`) over the tenant's private VRF `Alex-wan-vrf`. The Internet exit must hide the private addressing in every case. What the enterprise side accepts decides between the two designs: - **Use case B.** Alex Enterprise wants to see the real workload addresses, so that its firewall rules, logs and monitoring identify workloads directly, and it can route the tenant's private block `172.16.103.128/25`. - **Use case C.** Alex Enterprise accepts traffic only from the provider-assigned range `10.100.11.0/24`, or the tenant's private block cannot be routed in the enterprise because it overlaps with existing ranges. ## Topology ![Tenant Alex topology: two External Connections, workload on a Private-TGW subnet](https://msaad.pikapod.net/content/images/2026/09/ctgw-fig-tenant-alex-topology.png) Figure 1 – Tenant Alex topology: two External Connections (`Alex-wan-conn` on VRF `Alex-wan-vrf`, `Alex-internet-conn` on `Internet-T0`), one Centralized Transit Gateway, and the test workload `Alex-web-01` on the Private-TGW subnet. **Design at a glance.** The address plan is the reference plan from [Part 1](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-1-architecture-foundations/). | | Value | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | Project | Tenant-Alex, one Default Transit Gateway (CTGW) with two attachments | | Enterprise connection | Alex-wan-conn, centralized, on VRF Alex-wan-vrf; remote network 10.111.2.0/24 | | Internet connection | Alex-internet-conn, centralized, on Tier-0 Internet-T0; default route | | Enterprise-facing block | Alex-wan-block\_10.100.11.0/24, authorized on Alex-wan-conn; serves the public subnet, and in use case C the Provider SNAT pool | | Internet-facing block | Alex-internet-block\_10.100.21.0/24, authorized on Alex-internet-conn; the Auto SNAT block of the profile | | Private-TGW block | Alex-private-tgw-block\_172.16.103.128/25, the tenant's private block; advertised to the enterprise in use case B, translated in use case C | | Workload | Alex-web-01 172.16.103.131 on Alex-private-tgw-subnet 172.16.103.128/29 (Private-TGW) in VPC Alex-vpc-01 | | Test destinations | 10.111.2.2 in Alex Enterprise, 10.1.1.1 on the Internet | ## Why Private-TGW Is the Prerequisite Rule 1 applies Default Outbound NAT at different points depending on subnet type. For a Private-VPC subnet the rule is at the VPC gateway, so the packet reaches the CTGW already carrying an Auto SNAT address; the CTGW never sees the private address. For a Private-TGW subnet the rule is at the CTGW itself and is applied after the route lookup, so the CTGW still holds the original private address when it decides. That intact address is what advertisement forwards untranslated. Workloads the enterprise must see by their real addresses belong on a Private-TGW subnet. There is a second consequence: by default, traffic from Private-TGW subnets is actively dropped on External Connections. A Private-TGW workload reaches an External Connection only if something supplies a valid source address: Default Outbound NAT at the CTGW, a user-defined NAT rule, Provider SNAT on the connection, or advertisement of its block. Use case B uses advertisement on the enterprise connection and Default Outbound NAT on the Internet connection. ## Use Case B — The Enterprise Routes the Tenant's Private Block The enterprise routes `172.16.103.128/25` and wants to see the real workload addresses, so the design advertises the tenant's Private-TGW block over `Alex-wan-conn` and translates nothing on that path. The Internet path keeps the profile's Default Outbound NAT. ### Steady-state design | Object (Step) | Setting | Value | Purpose | | ---------------------------- | ------------------------------------------------------- | ---------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | External IP Blocks (1) | Blocks | Alex-wan-block\_10.100.11.0/24, Alex-internet-block\_10.100.21.0/24 | Enterprise-facing and Internet-facing ranges (the enterprise-facing block serves the public subnet) | | Alex-wan-conn (2) | Type / gateway | Centralized, VRF Alex-wan-vrf | Private link to Alex Enterprise | | | Remote Networks | Alex Enterprise prefixes | Steers only enterprise traffic here | | | External IP Blocks | Alex-wan-block | The public-subnet range advertised to the VRF | | | Provider Outbound SNAT | **Off** | Required: it cannot coexist with the next setting | | | Private – Transit Gateway IP Blocks | **On** | Permits the tenant to advertise its Private-TGW block here | | Alex-internet-conn (2) | Type / gateway | Centralized, Tier-0 Internet-T0 | Shared Internet exit | | | Remote Networks | Default route | Everything not matched elsewhere | | | External IP Blocks / Provider SNAT / Private-TGW blocks | Alex-internet-block / Off / Off | Accepts the Auto SNAT address; never learns the private block | | Project Tenant-Alex (3) | Connections / blocks | Both connections / both blocks | Makes them selectable inside the project | | Default Transit Gateway (4) | Connections | Alex-wan-conn and Alex-internet-conn | Two attachments, one default route | | | Advertise Rules | Alex-wan-conn: type Private-Transit Gateway | The tenant's half of the advertisement | | VPC Connectivity Profile (5) | External IP Blocks | Alex-wan-block, Alex-internet-block | Both ranges usable by VPCs | | | Private – Transit Gateway IP Blocks | Alex-private-tgw-block\_172.16.103.128/25 | The block that will be advertised | | | Default Outbound NAT / Auto SNAT block | **On** / Alex-internet-block | The Internet path's only translation | | VPC Alex-vpc-01 | Subnets | Alex-private-tgw-subnet 172.16.103.128/29 (workloads), Alex-public-subnet 10.100.11.8/29 | Workloads on the Private-TGW subnet | ### The workflow: two roles, one advertisement The advertisement is a two-role change. The provider toggle grants permission and advertises nothing by itself; the tenant's advertise rule chooses what is announced on that connection (public blocks, Private-TGW blocks, or both). Neither half does anything alone. **Provider space** **1\. Create the blocks.** `Alex-wan-block_10.100.11.0/24` and `Alex-internet-block_10.100.21.0/24` under **Networking > IP Address Pools > IP Address Blocks** in the Default project. **2\. Create the connections**, with the Private-Transit Gateway IP Blocks toggle enabled on `Alex-wan-conn` and Provider SNAT off: ```text Alex-wan-conn Type ................................ Centralized Tier-0 Gateway ...................... Alex-wan-vrf (VRF) Remote Networks ..................... Alex Enterprise prefixes (10.111.2.0/24) External IP Blocks .................. Alex-wan-block_10.100.11.0/24 Provider Outbound SNAT .............. Off (must be off before the next toggle can be enabled) Private – Transit Gateway IP Blocks . On Alex-internet-conn Type ................................ Centralized Tier-0 Gateway ...................... Internet-T0 (Tier-0) Remote Networks ..................... default route External IP Blocks .................. Alex-internet-block_10.100.21.0/24 Provider Outbound SNAT .............. Off Private – Transit Gateway IP Blocks . Off ``` **3\. Create the project** `Tenant-Alex` with both connections and both blocks assigned, one connection on the Default Transit Gateway, and the blocks pre-loaded into the Default VPC Connectivity Profile. **Tenant (project) space** **4\. Attach `Alex-internet-conn` to the Default Transit Gateway** through **Networking > Transit Gateways > ⋮ > Edit**, and wait for the status to change from **In Progress** to **Success**. **5\. Set the profile.** Under **VPC > Profiles > VPC Connectivity Profile > ⋮ > Edit**: both blocks under External IP Blocks; the project-owned private block `Alex-private-tgw-block_172.16.103.128/25` under Private – Transit Gateway IP Blocks (select an existing one or create it in place); Default Outbound NAT on with `Alex-internet-block` as the External IP Block for Default Outbound NAT. **6\. Add the advertise rule.** **Networking > Transit Gateways > expand the Default Transit Gateway > Routing and Forwarding > Advertise Rules**. For `Alex-wan-conn`, add the type **Private-Transit Gateway**. **7\. Create the VPC and subnets.** `Alex-vpc-01` with `Alex-private-tgw-subnet` `172.16.103.128/29` for the workloads and `Alex-public-subnet` `10.100.11.8/29` from the enterprise-facing block. ### What NSX programs automatically - **On the CTGW:** the Default Outbound NAT rule for the VPC, applied here, at the CTGW, for the workloads on the Private-TGW subnet, translating to `Alex-internet-block`. No Provider SNAT or No-SNAT rules exist, since Provider SNAT is off on both connections. - **Route advertisement:** toward `Alex-wan-vrf` the CTGW now announces the project's Private-TGW block `172.16.103.128/25` in addition to the authorized `Alex-wan-block` prefixes. The private block appears on the VRF as a TGW static route (`tgws`) and follows the existing BGP peering from the VRF to the physical router. That is how Alex Enterprise gets a return path to the tenant's real addresses. Toward `Internet-T0` only `Alex-internet-block` prefixes are advertised, so the private block stays invisible from the Internet side. > **Note:** This is the integration point with the enterprise. The `tgws` route on the VRF is what the provider's BGP session carries onward, so the tenant's private block becomes part of the enterprise routing domain. Hence the precondition: the block must be unique and routable on the enterprise side. ### Packet walks ![Use case B: Private-TGW advertisement, the enterprise path carries the real private address end to end](https://msaad.pikapod.net/content/images/2026/09/ctgw-fig-use-case-b-private-tgw-advertisement-2.png) Figure 2 – Private-TGW advertisement. The enterprise path carries the real private address end to end; only the Internet path is translated. **Path A — to the enterprise (`10.111.2.2`)** | Hop | Source → Destination | What happens | | ------------------------ | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1\. VM sends | 172.16.103.131 → 10.111.2.2 | Leaves the Private-TGW subnet | | 2\. VPC gateway | 172.16.103.131 → 10.111.2.2 | No translation: for a Private-TGW subnet the Default Outbound NAT rule is at the CTGW (Rule 1) | | 3\. CTGW route lookup | – | Rule 2: 10.111.2.2 is reachable through Alex-wan-conn | | 4\. CTGW source decision | 172.16.103.131 → 10.111.2.2 | Rule 3: the source is inside the block advertised on this connection, so it is forwarded untranslated; the Default Outbound NAT rule is not applied to this traffic | | 5\. Exit to Alex-wan-vrf | 172.16.103.131 → 10.111.2.2 | The VRF holds 172.16.103.128/25 as a tgws route; the enterprise sees and answers the real private address | | 6\. Reply | 10.111.2.2 → 172.16.103.131 | Plain routing back through the VRF and the CTGW to the VM; no NAT state involved | **Path B — to the Internet (`10.1.1.1`)** | Hop | Source → Destination | What happens | | ----------------------------- | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1\. VM sends | 172.16.103.131 → 10.1.1.1 | Leaves the same subnet | | 2\. CTGW route lookup | – | Default route through Alex-internet-conn | | 3\. CTGW Default Outbound NAT | 10.100.21.x → 10.1.1.1 | Rule 1 at the CTGW: one translation to the Auto SNAT block Alex-internet-block. Nothing is advertised on Alex-internet-conn, so the private address must be hidden here | | 4\. Exit to Internet-T0 | 10.100.21.x → 10.1.1.1 | Leaves with an address that Alex-internet-conn authorizes | ### Verification ```bash # From Alex-web-01 (172.16.103.131, Private-TGW subnet) ping 10.111.2.2 # Alex Enterprise, via Alex-wan-conn — expected: success, no NAT on the path ping 10.1.1.1 # Internet, via Alex-internet-conn — expected: success, one translation ``` ### Design notes - No NAT state on the enterprise path: nothing to fail over, nothing to exhaust, and enterprise logs show workload addresses directly. - The advertisement is scoped to one connection. The Internet connection keeps seeing the Auto SNAT block, so the private block is not exposed outside the enterprise link. - The public subnet `Alex-public-subnet` `10.100.11.8/29` is still advertised through `Alex-wan-block`; the private block is advertised in addition to it, not instead of it. - This design gives up Provider SNAT on that connection. If the enterprise later requires provider-owned addresses, the connection has to be switched to use case C. ## Use Case C — The Same Tenant, Provider-Owned Addresses The same workloads on the same Private-TGW subnet, but the enterprise accepts only the provider-assigned range `10.100.11.0/24`, or cannot route the private block. The design translates at the CTGW instead of advertising. ### Steady-state design This is use case A applied to a Private-TGW tenant. Compared with use case B, only the enterprise connection changes: | Object (Step) | Setting | Value | Purpose | | --------------------------- | --------------------------------------- | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Alex-wan-conn (2) | Provider Outbound SNAT / SNAT IP Blocks | **On** / Alex-wan-block\_10.100.11.0/24 | Translates every enterprise-bound source to the provider range | | | Private – Transit Gateway IP Blocks | Off | Cannot coexist with Provider SNAT | | Default Transit Gateway (4) | Advertise Rules | None for Private-TGW | Nothing private is announced | | Everything else | | As in use case B | Alex-internet-conn with Alex-internet-block; profile with Default Outbound NAT on and Alex-internet-block as the Auto SNAT block | > **Note:** The two connection settings are mutually exclusive. Use case C's enterprise connection has the Private-TGW IP Blocks toggle off and no Private-Transit Gateway advertise rule, with Provider Outbound SNAT on. ### What NSX programs automatically On the CTGW: the Default Outbound NAT rule for the VPC (Private-TGW subnets are translated at the CTGW) toward `Alex-internet-block`, plus, scoped to `Alex-wan-conn`, the Provider SNAT rule toward `Alex-wan-block` and the No-SNAT rule for already-authorized sources. All translation for this tenant happens on the CTGW. ### Packet walks ![Use case C: Provider SNAT on a Private-TGW subnet, both paths translated exactly once at the CTGW](https://msaad.pikapod.net/content/images/2026/09/ctgw-fig-use-case-c-provider-snat-private-tgw-2.png) Figure 3 – Provider SNAT on a Private-TGW subnet. Both paths are translated exactly once, at the CTGW. **Path A — to the enterprise (`10.111.2.2`)** | Hop | Source → Destination | What happens | | ------------------------ | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | 1\. VM sends | 172.16.103.131 → 10.111.2.2 | Leaves the Private-TGW subnet | | 2\. VPC gateway | 172.16.103.131 → 10.111.2.2 | No translation (Rule 1) | | 3\. CTGW route lookup | – | 10.111.2.2 is reachable through Alex-wan-conn | | 4\. CTGW Provider SNAT | 10.100.11.x → 10.111.2.2 | Provider SNAT is on here and the private source is not in an authorized block, so it is translated once, to the SNAT IP Block Alex-wan-block | | 5\. Exit to Alex-wan-vrf | 10.100.11.x → 10.111.2.2 | The enterprise sees only the authorized 10.100.11.0/24 range | | 6\. Reply | 10.111.2.2 → 10.100.11.x | The CTGW reverses the translation and delivers 10.111.2.2 → 172.16.103.131 | **Path B — to the Internet (`10.1.1.1`)** | Hop | Source → Destination | What happens | | ----------------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 1\. VM sends | 172.16.103.131 → 10.1.1.1 | Leaves the same subnet | | 2\. CTGW route lookup | – | Default route through Alex-internet-conn | | 3\. CTGW Default Outbound NAT | 10.100.21.x → 10.1.1.1 | Provider SNAT is off on Alex-internet-conn, so the Default Outbound NAT rule translates once, to the Auto SNAT block Alex-internet-block. A user-defined TGW NAT rule, if one existed, would take precedence | | 4\. Exit to Internet-T0 | 10.100.21.x → 10.1.1.1 | Leaves with an address that Alex-internet-conn authorizes | ### Why each element is necessary - **Provider Outbound SNAT on `Alex-wan-conn`.** Without it the CTGW applies Default Outbound NAT to enterprise-bound traffic as well, producing `10.100.21.x`, which is not routable through `Alex-wan-conn`: `10.111.2.2` is unreachable. - **Private-TGW toggle off on that connection.** Mutually exclusive with Provider SNAT; Provider SNAT cannot be enabled while the toggle is on. - **Default Outbound NAT on with `Alex-internet-block`.** The Internet path has no other translation. Without it the Private-TGW workloads have no source address that `Alex-internet-conn` authorizes and cannot reach the Internet: `10.1.1.1` is unreachable. ### Design notes - The CTGW is the single NAT point for this scenario: whichever connection a packet leaves by, it is translated exactly once. Use case A translated the enterprise-bound packet twice because its first translation happened at the VPC gateway. - The enterprise sees a provider-owned range, as in use case A, and the tenant's private addressing stays hidden on both exits. ## What Comes Next Parts 2 and 3 used each source-address behaviour on its own: Default Outbound NAT toward the Internet, Provider SNAT toward an enterprise, advertisement toward an enterprise. Provider SNAT and advertisement are per connection; Default Outbound NAT belongs to the profile. Can one gateway do all three at once? [Part 4](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-4-one-tenant-three-exits/) answers with Riyadh, a single tenant with three External Connections: a dedicated VRF to its enterprise data centre that must see Private-TGW addresses directly, a provider-operated shared-services network that must see every tenant only through a provider pool, and the Internet. With workloads on all three subnet types that is nine source-and-exit combinations, and [Part 4](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-4-one-tenant-three-exits/) walks through every one. **Series: [CTGW External Connectivity in VCF 9.1](https://msaad.pikapod.net/ctgw-external-connectivity-vcf-9-1/)** — Part 3 of 5 [Intro: Tenant Topology for Cloud Providers running VCF9.1](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-introduction/) · [1\. Architecture and Foundations](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-1-architecture-foundations/) · [2\. Use-Case A Private-VPC Connectivity to External Networks (Translated)](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-2-provider-snat-private-vpc/) · **3\. Use-Case B&C Private-TGW Connectivity to External Networks (Routed or Translated)** · [4\. Use-Case D One Tenant, Three Exits](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-4-one-tenant-three-exits/) · [5\. Operating the Designs](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-5-operating-the-designs/)