> ## 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. # 1. Architecture and Foundations - URL: https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-1-architecture-foundations/ - Published: 2026-09-12T13:35:42.000Z - Updated: 2026-09-13T14:48:44.000Z - Description: VCF 9.1 lets a Centralized Transit Gateway attach to more than one External Connection, and adds two provider-side controls that decide what source address a tenant packet carries at each exit. Part 1 covers the objects, the build order, and the rules every later design depends on. - Author: Mohammad Saad - Tags: VCF 9.1, NSX, Transit Gateway, VPC Networking, Multi-Tenancy, Series: CTGW External Connectivity **Series: [CTGW External Connectivity in VCF 9.1](https://msaad.pikapod.net/ctgw-external-connectivity-vcf-9-1/)** — Part 1 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** · [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)](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-3-private-tgw-advertisement-provider-snat/) · [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/) In VCF 9.1 a Centralized Transit Gateway (CTGW) can attach to **more than one External Connection**. One tenant gateway can hold a private link to the tenant's enterprise network, a link to a provider services network, and the default route to the Internet at the same time. Two new provider-side controls on the External Connection, **Provider Outbound SNAT** and **Private-TGW IP block advertisement**, decide what source address a tenant packet carries when it leaves through each connection. Set them right and one gateway serves three exits with three address policies. Set them wrong and traffic silently has no return path. This series builds the objects in order, shows where every IP block field gets its value, and then walks four complete steady-state designs packet by packet. This part covers the object model, the build order, the four rules, and the reference environment used in Parts 2 and 3. **The series at a glance** | Part | Covers | | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | **Part 1** (this article) | Objects, build order, IP-block sourcing, the four source-address rules, the reference environment | | [Part 2](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-2-provider-snat-private-vpc/) | Use case A: Private-VPC workloads; the enterprise must see provider-owned addresses (Provider SNAT) | | [Part 3](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-3-private-tgw-advertisement-provider-snat/) | Use cases B and C: Private-TGW workloads, advertised to the enterprise untranslated or translated by Provider SNAT | | [Part 4](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-4-one-tenant-three-exits/) | Use case D: one tenant with three exits (enterprise DC, shared services, Internet), each with its own source-address rule | | [Part 5](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-5-operating-the-designs/) | Design comparison, lifecycle procedures, verification, governance | ## Who This Is For Two roles share the work. **Provider administrators** create External IP Blocks and External Connections in the NSX Default project, and the customer-defined Projects. **Project (tenant) administrators** use them inside the project through the Transit Gateway and the VPC Connectivity Profile. Each step is marked with its space, because several behaviours need one action from each role before anything happens. ## Terminology | Term | Meaning in this series | | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **CTGW** | Centralized Transit Gateway: a tenant's transit hub, backed by an edge cluster and connected to the provider through Tier-0 or Tier-0 VRF gateways | | **External Connection** | The provider-created peering point between a Transit Gateway and the outside. Centralized connections terminate on a Tier-0 or Tier-0 VRF | | **External IP Block** | A provider-owned, routable address range. Public subnets, external IPs and NAT addresses are allocated from it | | **Public subnet** | A VPC subnet whose addresses come from an External IP Block and are advertised northbound | | **Private-VPC subnet** | A VPC subnet with private addressing, scoped to its VPC. It reaches anything outside the VPC only through NAT | | **Private-TGW subnet** | A VPC subnet with private addressing, scoped to the project: reachable from the other VPCs on the same Transit Gateway without NAT. It reaches an External Connection through NAT at the CTGW or through advertisement | | **Auto SNAT block** | The *External IP Block for Default Outbound NAT* chosen in the VPC Connectivity Profile; the Default Outbound NAT rule takes its translated address from it | | **Enterprise connection** | The External Connection to a tenant's own enterprise network through a dedicated VRF (Cairo-wan-conn, Alex-wan-conn, Riyadh-wan-conn) | | **Shared-services connection** | In [Part 4](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-4-one-tenant-three-exits/), the External Connection to a services network the provider offers to all tenants (Shared-services-conn) | | **Internet connection** | The External Connection that carries the default route to the Internet through the shared Tier-0 Internet-T0 (Cairo-internet-conn, Alex-internet-conn, Riyadh-internet-conn) | **Naming used throughout.** Objects are named `--`: the tenant name first, then what the object is for, then what it is (`Cairo-wan-conn`, `Cairo-wan-block_10.100.10.0/24`, `Cairo-private-tgw-subnet`). VPCs and workloads carry a running number instead (`Cairo-vpc-01`, `Cairo-web-01`). Objects the provider offers to every tenant carry no tenant prefix (`Shared-services-conn`, `Internet-T0`). Projects are named after the tenant (`Tenant-Cairo`). ## The End-to-End Flow The provider creates External IP Blocks, then External Connections that authorize those blocks, then a Project that receives a subset of both. Inside the project, the Transit Gateway consumes one or more of those connections and the VPC Connectivity Profile consumes the blocks. In Step 6 the provider sets advanced settings on the connection that change how the tenant's traffic leaves. ![The six objects in build order: three provider steps, two tenant steps, then the advanced settings on the connection](https://msaad.pikapod.net/content/images/2026/09/ctgw-fig-build-order-simple.png) Figure 1 – The six objects in build order. Steps 1–3 and 6 belong to the provider administrator, steps 4 and 5 to the project administrator. ![How the six steps reference each other: provider space above, tenant project below](https://msaad.pikapod.net/content/images/2026/09/ctgw-fig-build-order-2.png) Figure 2 – How the six steps reference each other. Solid arrows are the build order; dashed amber arrows show where IP blocks are pulled from; the solid amber arrow is the behaviour set on the connection in Step 6. Every field that asks for an IP block is filled from a list produced by an earlier step. Following the dashed arrows backwards answers a good number of "why can't I select this block?" questions. ## Step 1 — Create External IP Blocks (Provider Space) **Where.** NSX Manager, Default project, **Networking > IP Address Pools > IP Address Blocks**. **What they are.** Routable address ranges the provider owns. They supply VPC public subnets and individual /32 external IPs (load balancer VIPs, VPN endpoints). Those subnets and IPs are advertised northbound through any External Connection that authorizes the block. The same blocks also supply the addresses used by Default Outbound NAT and by Provider SNAT. **Naming.** Name each block after the tenant and the exit it serves, with the CIDR in the name, because every later step refers to the block by name only. This series uses `--block_`: `Cairo-wan-block_10.100.10.0/24` faces Cairo's enterprise network and `Cairo-internet-block_10.100.20.0/24` faces the Internet. A provider-wide pool carries no tenant prefix (`Shared-services-snat-block_10.99.0.0/24`). In running text the CIDR is dropped after the first mention. ## Step 2 — Create External Connections (Provider Space) **Where.** Default project, **Networking > VPC Connectivity > External Connections > Add External Connection**. **What it is.** The peering point between the provider and a tenant, and the point where North-South routing, Gateway Firewall scoping and NAT are applied. It terminates on a Tier-0 or Tier-0 VRF gateway (centralized) or on a VLAN or VXLAN fabric (distributed). Since VCF 9.1 a Transit Gateway can attach to several External Connections at once; that is what the advanced settings below are for. **Fields.** | Field | Value | | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Name | Tenant and exit, for example Cairo-wan-conn or Cairo-internet-conn | | Type | Centralized (Tier-0 or Tier-0 VRF); Distributed VLAN (optionally *Dedicated to Subnet* for Layer 2 extension); or Distributed VXLAN (BGP EVPN through the VCF Route Controller) | | Tier-0 Gateway | The gateway that terminates a centralized connection | | Remote Networks | The destinations reachable through this connection. Leave empty or enter 0.0.0.0/0 for the default route; otherwise list the CIDRs. A CTGW with several connections can carry the default route on only one of them; every other connection needs explicit remote networks. Remote networks must be unique per connection (no ECMP) and are installed as PROVIDER\_STATIC routes with administrative distance 10 | | External IP Blocks | The blocks from Step 1 that this connection authorizes. Only prefixes from these blocks are advertised northbound over this connection, as TGW static routes. The default is all blocks | | Private – Transit Gateway IP Blocks | Toggle that lets tenants advertise their Private-TGW blocks over this connection. Cannot be enabled together with Provider Outbound SNAT | | Provider Outbound SNAT | Provider-managed SNAT for traffic leaving this connection. Enabling it also creates a No-SNAT rule for sources that already belong to the connection's authorized blocks | | SNAT IP Blocks | The block Provider SNAT translates to. Must be one of this connection's authorized External IP Blocks; the dropdown offers only those | > **Note:** Remote Networks is what turns a set of connections into a routing table. Exactly one connection may carry the default route; every other one must list explicit prefixes, and no prefix may appear on two connections. **Typical design.** One enterprise connection per tenant (specific remote networks, the tenant's enterprise-facing block `-wan-block` authorized, and either Provider SNAT or Private-TGW advertisement enabled) and one Internet connection on the shared Internet Tier-0 (default route, the tenant's Internet-facing block `-internet-block` authorized, Provider SNAT off). Parts 2 to 4 show how traffic behaves in this design. ## Step 3 — Create the Project and Assign Connections and Blocks (Provider Space) **Where.** Project drop-down at the top of NSX Manager > **Manage** \> Add Project. In VCF 9.1 the project dialog assigns external connections, external IP blocks, an edge cluster and a network span in one place, and maps them to the project's default Transit Gateway and default VPC Connectivity Profile. **Set External Connections** (dialog inside the project form): - **External Connections** – the connections from Step 2 that VPCs in this project may use. - **External Connections for Default Transit Gateway** – a subset of the above: the connection attached to the project's default Transit Gateway when the project is created. **Set External IP Blocks** (dialog inside the project form): - **External IP Blocks** – the blocks from Step 1 that this project may consume. - **External IP Blocks for Default VPC Connectivity Profile** – up to five of those blocks, pre-loaded into the project's default profile. **Result.** The project now owns a Default Transit Gateway with one connection and a Default VPC Connectivity Profile with the chosen blocks. Steps 4 and 5 are edits to those two objects. ## Step 4 — Transit Gateway (Project Space) **Where.** Inside the project, **Networking > Transit Gateways**. The Default Transit Gateway is created with the project, using the connection chosen in Step 3\. Use **Add Transit Gateway** for an additional gateway, or **⋮ > Edit** to change an existing one. **What it is.** The hub that connects the project's VPCs, its External Connections and its remote networks. It belongs to one project and cannot span projects. **Step A – Transit Gateway Connectivity.** | Field | Notes | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Gateway Name | Required | | Span | The Network Span (a set of vCenter clusters) that can see this gateway and its VPCs. A gateway outside a vCenter's span is not shown in that vCenter | | Connection | None, Centralized, Distributed VLAN or Distributed VXLAN. Centralized creates a CTGW with gateway services; the distributed options create a DTGW | | High Availability Mode | Active Standby (default) or Active Active. In VCF 9.1 the CTGW uses independent HA on its own edge nodes, with no fate sharing with the Tier-0 | | TGW Edge Cluster | The shared or dedicated edge cluster that hosts the CTGW | **Step B – Workload Domain Connectivity.** | Field | Notes | | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | External Connection | Required. One connection at creation; more can be attached later through Edit | | VPC External IP Blocks | Up to five. Each must be authorized on the connection. These become the External IP Blocks of the default VPC Connectivity Profile | | Private – Transit Gateway IP Blocks | Up to five. Select an existing project-owned private block or create one | | Default Outbound NAT | When on, NSX auto-plumbs one SNAT rule per VPC. The rule applies to both private subnet types: at the VPC gateway for Private-VPC subnets, at the CTGW for Private-TGW subnets. When off, there is no default translation: Private-VPC subnets stay confined to their VPC and Private-TGW subnets stay reachable only across the VPCs of the same Transit Gateway, unless a user NAT rule, Provider SNAT or Private-TGW advertisement supplies a source address. User-defined NAT rules take priority over the default rule | **Attaching another connection.** Edit the Default Transit Gateway, pick the additional connection 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**. ## Step 5 — VPC Connectivity Profile (Project Space) **Where.** Inside the project, **VPC > Profiles > VPC Connectivity Profile**. The default profile was generated in Steps 3 and 4; edit it with **⋮ > Edit**, or use **Add VPC Connectivity Profile** for VPCs that need different blocks or services. A project can hold several profiles, and many VPCs can share one. **Profile fields.** | Field | Notes | | ----------------------------------- | ------------------------------------------------------------------------ | | Name | Required | | Transit Gateway | Defaults to the Default Transit Gateway of Step 4 | | External IP Blocks | Up to five. They must have been assigned to the project in Step 3 | | Private – Transit Gateway IP Blocks | Up to five. Select an existing project-owned private block or create one | | VPC | Read-only list of the VPCs that use this profile | **VPC Service Gateway Configurations.** | Field | Notes | | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Edge Cluster | Required. Hosts the per-VPC service instance; for a DTGW this is the VNA cluster | | N-S Services | Enables centralized services on the VPC gateway. When on, additional service options appear under VPC Config in vCenter | | Default Outbound NAT | When on, NSX auto-plumbs one SNAT rule per VPC. The rule applies to both private subnet types: at the VPC gateway for Private-VPC subnets, at the CTGW for Private-TGW subnets. When off, there is no default translation: Private-VPC subnets stay confined to their VPC and Private-TGW subnets stay reachable only across the VPCs of the same Transit Gateway, unless a user NAT rule, Provider SNAT or Private-TGW advertisement supplies a source address. User-defined NAT rules take priority over the default rule | | External IP Block for Default Outbound NAT | New in VCF 9.1\. The block that supplies the translated address for the rule above; it must be one of this profile's External IP Blocks. This series calls it the **Auto SNAT block** | | N-S Ingress / Egress QoS Profile | Optional gateway QoS profiles | **Why the block choice matters.** The Auto SNAT block belongs to the profile, so the Default Outbound NAT rule applies the same address to every destination, whichever connection the packet leaves through. A connection forwards a packet only if its source belongs to a block the connection authorizes. One Auto SNAT block can therefore satisfy only one connection's authorization list. Choose the block that the default-route connection (normally the Internet connection) authorizes, and let Step 6 handle the other connections. You can see the effect directly: with the Auto SNAT block set to the Internet block, the Internet becomes reachable while the enterprise connection, which authorizes a different block, stops forwarding the tenant's traffic until Provider SNAT or advertisement is enabled on it. Parts 2 and 3 show both remedies. ## Step 6 — Advanced Settings on the External Connection (Provider Space) Both settings are edited on the External Connection in the Default project (**Networking > VPC Connectivity > External Connections > ⋮ > Edit**). They are mutually exclusive on a given connection: **Provider Outbound SNAT must be disabled before Private-TGW IP Blocks can be enabled.** ### 6a. Provider Outbound SNAT Enable the toggle and choose the SNAT IP Block from the connection's authorized External IP Blocks. From then on, any packet leaving through this connection with a source outside the authorized blocks is translated to an address from the SNAT IP Block. Packets whose source is already inside the authorized blocks pass unchanged, through an automatically created No-SNAT rule. For a Private-VPC subnet this is a second translation, after Default Outbound NAT at the VPC gateway. For a Private-TGW subnet it is the only translation, performed at the CTGW. The setting is per connection and has no effect on the tenant's other connections. ### 6b. Private-TGW IP Block Advertisement Two steps, two roles: 1. **Provider:** enable the **Private-Transit Gateway IP Blocks** toggle on the connection and save. This grants permission and advertises nothing by itself. 2. **Project administrator:** in the project, open **Transit Gateways > expand the Default Transit Gateway > Routing and Forwarding > Advertise Rules**, and for that connection add the type **Private-Transit Gateway**. The tenant chooses what is announced on the connection: public blocks, Private-TGW blocks, or both. Once both steps are done, the project's Private-TGW block is advertised over that connection and appears on the provider gateway as a TGW static route (`tgws`). Traffic from Private-TGW subnets toward that connection keeps its real private address. Traffic toward the Internet connection is still translated by Default Outbound NAT. > **Note:** Both halves are required. A toggle without a rule announces nothing; a rule without the toggle has nothing to act on. [Part 3](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-3-private-tgw-advertisement-provider-snat/) builds this workflow step by step. ## Quick Reference: Where Each IP Block Comes From | Used in | Field | Pulled from | | ------------------------------------------ | ------------------------------------------------------------ | --------------------------------------------------------- | | External Connection (Step 2) | External IP Blocks | Provider IP Address Blocks (Step 1) | | External Connection (Step 2) | SNAT IP Blocks | That connection's External IP Blocks | | Project (Step 3) | External IP Blocks | Provider IP Address Blocks (Step 1) | | Project (Step 3) | Blocks for Default VPC Connectivity Profile | Project's External IP Blocks (Step 3) | | Transit Gateway (Step 4) | VPC External IP Blocks | Project's External IP Blocks (Step 3) | | Connectivity Profile (Step 5) | External IP Blocks | Project's External IP Blocks (Step 3) | | Connectivity Profile (Step 5) | External IP Block for Default Outbound NAT (Auto SNAT block) | That profile's External IP Blocks | | Transit Gateway or Profile (Steps 4 and 5) | Private – Transit Gateway IP Blocks | Project-owned private block, selected or created in place | ## The Four Rules That Decide the Source Address Four rules, in the order a packet meets them, explain every packet walk in this series. **Rule 1 — Default Outbound NAT is the first translation, and it belongs to the VPC Connectivity Profile.** It applies to both private subnet types. When the profile's Default Outbound NAT toggle (Step 5) is on, NSX auto-plumbs one SNAT rule per VPC, and the translated address comes from the profile's Auto SNAT block. The difference between the subnet types is **where the rule is applied**. For a **Private-VPC** subnet it is applied at the VPC gateway, so the packet reaches the CTGW already carrying an Auto SNAT address. For a **Private-TGW** subnet it is applied at the CTGW itself, after the route lookup, so the CTGW still holds the original private address when it decides. When the toggle is off there is no default translation for either type: a Private-VPC subnet stays confined to its VPC, and a Private-TGW subnet stays reachable only from the other VPCs on the same Transit Gateway. Neither reaches an External Connection unless something else supplies the source address: a user NAT rule, Provider SNAT on the connection, or Private-TGW advertisement. **Rule 2 — The CTGW routes first: the destination selects the exit connection.** Before any NAT decision, the CTGW looks up the destination in its routing table, like any router. The table is built from the attached External Connections: every prefix under a connection's Remote Networks (Step 2) becomes a static route to that connection, and the one connection with no remote networks, or `0.0.0.0/0`, supplies the default route. The most specific route wins; a destination that matches no listed prefix takes the default route. The lookup picks the exit connection; only then does Rule 3 apply. In the reference environment below, `10.111.1.1` matches the remote networks of `Cairo-wan-conn` and exits there; `10.1.1.1` matches nothing specific and takes the default route through `Cairo-internet-conn`. Two limits follow: a CTGW can hold only one default route, and a remote network prefix can be listed on only one connection (no ECMP between connections). **Rule 3 — Then the exit connection decides what happens to the source.** With Provider SNAT enabled, the CTGW compares the packet's current source with the connection's authorized External IP Blocks: no match means a translation to the connection's SNAT IP Block; a match means the packet passes unchanged. With Provider SNAT disabled there is no check. With Private-TGW advertisement enabled on the connection and an advertise rule on the gateway, a Private-TGW source is forwarded untranslated. **Rule 4 — A source that is not authorized on the exit connection does not get through.** The CTGW advertises only the authorized blocks to the provider gateway, so a packet carrying any other source has no return path. > **Note:** Most common failures in such architectures are Rule 4 failures: the packet leaves with a source the exit connection never advertised, so it has no return path. The other cause would be Rule 2: no route to the destination at all, which is what a gateway without a default route looks like. ## The Reference Environment: a Simple Tenant Topology with WAN and Internet Connectivity Parts 2 and 3 share one environment. Each tenant has its own VRF toward its enterprise network and shares the Internet Tier-0 (`Internet-T0`) toward the Internet. Both tenants receive one enterprise-facing block and one Internet-facing block, and each of the four External Connections authorizes exactly one of them. ![Reference topology: two tenants, four External Connections, and the block each connection authorizes](https://msaad.pikapod.net/content/images/2026/09/ctgw-fig-reference-topology-2.png) Figure 3 – Reference topology: two tenants, four External Connections, and the block each connection authorizes. The highlighted subnet in each project hosts the test VM. **Design at a glance.** | | Cairo (project Tenant-Cairo) | Alex (project Tenant-Alex) | | ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Test workload | Cairo-web-01, 192.168.10.3, on the **Private-VPC** subnet Cairo-private-vpc-subnet | Alex-web-01, 172.16.103.131, on the **Private-TGW** subnet Alex-private-tgw-subnet | | Enterprise destination | 10.111.1.1 (Cairo Enterprise) | 10.111.2.2 (Alex Enterprise) | | Enterprise connection | Cairo-wan-conn, on VRF Cairo-wan-vrf | Alex-wan-conn, on VRF Alex-wan-vrf | | Internet connection | Cairo-internet-conn, on Internet-T0, default route to 10.1.1.1 | Alex-internet-conn, on Internet-T0, default route to 10.1.1.1 | | Enterprise-facing block (authorized on the enterprise connection) | Cairo-wan-block\_10.100.10.0/24 | Alex-wan-block\_10.100.11.0/24 | | Internet-facing block (authorized on the Internet connection) | Cairo-internet-block\_10.100.20.0/24 | Alex-internet-block\_10.100.21.0/24 | | Private-TGW block of the project | Cairo-private-tgw-block\_172.16.103.0/25 | Alex-private-tgw-block\_172.16.103.128/25 | | Design used | Use case A ([Part 2](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-2-provider-snat-private-vpc/)) | Use case B ([Part 3](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-3-private-tgw-advertisement-provider-snat/)), with use case C as the alternative | **Address plan.** Every range in the design, where it is created, and what it is used for. | Range | Name | Kind / created in | Authorized on / used by | Role | | -------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------- | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 10.100.10.0/24 | Cairo-wan-block\_10.100.10.0/24 | External IP Block, Default project (Step 1) | Cairo-wan-conn; project Tenant-Cairo | Cairo's enterprise-facing range: public subnet Cairo-public-subnet 10.100.10.8/29 and the Provider SNAT pool in use case A | | 10.100.11.0/24 | Alex-wan-block\_10.100.11.0/24 | External IP Block, Default project (Step 1) | Alex-wan-conn; project Tenant-Alex | Alex's enterprise-facing range: public subnet Alex-public-subnet 10.100.11.8/29 and the Provider SNAT pool in use case C | | 10.100.20.0/24 | Cairo-internet-block\_10.100.20.0/24 | External IP Block, Default project (Step 1) | Cairo-internet-conn; project Tenant-Cairo | Cairo's Internet-facing range: Auto SNAT block of Cairo's profile | | 10.100.21.0/24 | Alex-internet-block\_10.100.21.0/24 | External IP Block, Default project (Step 1) | Alex-internet-conn; project Tenant-Alex | Alex's Internet-facing range: Auto SNAT block of Alex's profile | | 172.16.103.0/25 | Cairo-private-tgw-block\_172.16.103.0/25 | Private block, project Tenant-Cairo | Cairo's profile | Source of the Private-TGW subnet Cairo-private-tgw-subnet 172.16.103.0/29 | | 172.16.103.128/25 | Alex-private-tgw-block\_172.16.103.128/25 | Private block, project Tenant-Alex | Alex's profile | Source of the Private-TGW subnet Alex-private-tgw-subnet 172.16.103.128/29; advertised over Alex-wan-conn in use case B | | 192.168.10.0/24 | Cairo-private-vpc-block\_192.168.10.0/24, Alex-private-vpc-block\_192.168.10.0/24 | Private block, each project | Each tenant's VPC | Source of the Private-VPC subnets Cairo-private-vpc-subnet and Alex-private-vpc-subnet, both 192.168.10.0/29. The same range in both projects is harmless because Private-VPC subnets are never advertised | | 100.64.0.0/31 | – | Transit link, automatic | Transit Gateway ↔︎ VPC gateway | Point-to-point link between the Default Transit Gateway (100.64.0.0) and the VPC gateway (100.64.0.1) | | 10.111.1.1, 10.111.2.2, 10.1.1.1 | – | Test destinations, physical network | – | Cairo Enterprise, Alex Enterprise and the Internet, all behind the physical router that peers with the three provider gateways over BGP | ## The Four Designs Ahead Each of the next three parts starts from a requirement and gives the design that meets it: the configuration object by object, what NSX programs automatically, the packet walks, and the verification. | Use case | Workload subnet | What the enterprise must see | Design | Covered in | | -------- | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | A | Private-VPC | Provider-owned addresses only | Provider SNAT on the enterprise connection | [Part 2](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-2-provider-snat-private-vpc/) | | B | Private-TGW | The tenant's private TGW addresses | Private-TGW IP block advertisement | [Part 3](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-3-private-tgw-advertisement-provider-snat/) | | C | Private-TGW | Provider-owned addresses only | Provider SNAT on the enterprise connection | [Part 3](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-3-private-tgw-advertisement-provider-snat/) | | D | Public, Private-TGW and Private-VPC | The DC sees the Private-TGW addresses; the provider services see a provider pool; the Internet sees the Auto SNAT block | Advertisement on the enterprise connection, Provider SNAT on the shared-services connection, Default Outbound NAT toward the Internet | [Part 4](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-4-one-tenant-three-exits/) | Use cases A, B and C share the reference topology above. Use case D has its own topology: one tenant with three External Connections, combining all three behaviours in one gateway. ## What Comes Next The open question is how the provider keeps control while the tenant administrator consumes services securely: tenant isolation must hold, the tenant's Private-VPC and Private-TGW addressing must keep working inside the project, and the workloads must still reach external networks, whether the enterprise's own sites over the WAN, the Internet, or shared cloud services. Which networking, security and connectivity features achieve that with full flexibility, strong tenant isolation and provider control? [Part 2](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-2-provider-snat-private-vpc/) gives the first answer, starting with Cairo's Private-VPC workloads. **Series: [CTGW External Connectivity in VCF 9.1](https://msaad.pikapod.net/ctgw-external-connectivity-vcf-9-1/)** — Part 1 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** · [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)](https://msaad.pikapod.net/vcf-91-ctgw-external-connectivity-part-3-private-tgw-advertisement-provider-snat/) · [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/)