--- name: vmwaresolutions-arch-pattern-nsx-t-private-connectivity title: Architecture patterns for vCenter Server deployment with private connectivity options description: As of 17 July 2025, new automated installations of Red Hat® OpenShift® for VMware® are no longer available for new or existing deployments of VMware Cloud Foundation for Classic - Automated instances. You can still use or delete your existing Red Hat OpenShift for VMware automated installations until 16 July 2026. The service will no longer be available from 17 July 2026. last-updated: 2025-10-24 --- > ## Documentation Index > The table of contents for this documentation set is at https://cloud.ibm.com/docs/vmwaresolutions?format=markdown > The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt > Use these files to discover more information as needed. # Architecture patterns for vCenter Server deployment with private connectivity options {: #arch-pattern-nsx-t-private-connectivity} As of 17 July 2025, new automated installations of Red Hat® OpenShift® for VMware® are no longer available for new or existing deployments of VMware Cloud Foundation for Classic - Automated instances. You can still use or delete your existing Red Hat OpenShift for VMware automated installations until 16 July 2026. The service will no longer be available from 17 July 2026. {: deprecated} When you deploy a [VCF for Classic - Automated](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_vcenterserveroverview&format=markdown) instance in your IBM Cloud® classic infrastructure, the deployment consists of a number of network constructs and VMware® management components. These architecture patterns give an overview for a few private connectivity options for VMware Cloud Foundation for Classic - Automated deployments. ## Private connectivity deployed by automation {: #arch-pattern-nsx-t-private-connectivity-depl-auto} When you deploy a VCF for Classic - Automated instance in your IBM Cloud classic infrastructure, you obtain the default private network topology as presented in the following diagram. ![Access to IBM Cloud Private network](../../images/arch-pattern-nsx-t-private-access.svg "Access to IBM Cloud Private network"){: caption="Access to IBM Cloud private network" caption-side="bottom"} The following list summarizes the private connectivity pattern. 1. The automation deploys an NSX Tier 0 (T0) Gateway in the NSX workload edge cluster. The T0 gateway provides connectivity to IBM Cloud private network. 2. The deployed T0 gateway has a route to IBM Cloud private network `10.0.0.0/8` and IBM Cloud Services networks `166.8.0.0/14` and `161.26.0.0/16` with BCR as a next-hop. 3. The automation deploys an example NSX overlay topology with a Tier 1 (T1) Gateway and a few example segments attached both to the T1 and T0 Gateways. You might customize the topology based on your needs. 4. IBM Cloud Services can be reached through IBM Cloud private network by using Cloud Services Endpoints when it uses IBM Cloud private network addresses. 5. When you use BYOIP on NSX overlay networks, you must use SNAT at T0 or T1. If you use SNAT at T1, you can advertise the NAT IP addresses from T1 to T0, where proxy ARP is used. 6. You can create DNAT rules on T0 Gateway to access your workloads from IBM Cloud private networks. 7. You can use IP addresses from IBM Cloud private portable subnet that is deployed for NSX Edge uplinks for the NAT. Alternatively, you can order [IBM Cloud Private static subnets](https://cloud.ibm.com/docs/subnets?topic=subnets-getting-started&format=markdown) that are routed toward your T0's private high availability (HA) VIP to be used for NAT-ing or on segments. ## Ingress private connectivity {: #arch-pattern-nsx-t-private-connectivity-ingress} Private ingress connectivity to NSX overlay is enabled through NAT or though using overlay tunnels. You can use IP addresses from the private portable subnet that is provisioned for T0 private uplinks for these use cases. ![Private ingress access to IBM Cloud NSX overlay](../../images/arch-pattern-nsx-t-private-access-ingress.svg "Private ingress access to IBM Cloud NSX overlay"){: caption="Private ingress access to IBM Cloud NSX overlay" caption-side="bottom"} The following steps summarize this architecture pattern deployment. 1. The automation deploys an NSX T0 Gateway in the NSX workload edge cluster. The T0 gateway provides connectivity to the IBM Cloud private network. 2. The automation deploys an example NSX overlay topology with a T1 Gateway and a few example segments attached both to the T1 and T0 Gateways. You can customize the topology based on your needs. 3. Workload T0 Gateway has a private uplink that is attached to the IBM Cloud private VLAN with three IP addresses, two for uplinks in edge 1 and edge 2 and one for HA VIP. Interfaces are configured with the network mask of the private portable subnet. The NSX T0 uplink does not support secondary IP addresses. {: note} 4. You can configure DNAT rules on T0 or T1 for ingress access, or SNAT for egress access from NSX overlay by using the IP addresses from the private portable subnet configured in the T0 uplinks. You can also configure load balancer VIPs, IPsec, or L2 VPN. Each of these are advertised as `/32` host IP addresses. You need to enable route advertisements on T1 Gateways so that T0 is aware of these IP addresses, and they must appear on T0s routing table. 5. T0 Gateway uses proxy ARP on the uplink subnet for each `/32` IP address that is aware of (that is, which exists in its routing table). BCR can route ingress traffic only to these IP addresses. To check the routing table of T0, use the NSX GUI or log in to the NSX edge node and its T0 Service Router (SR) VRF. With [IBM Cloud Private static subnets](https://cloud.ibm.com/docs/subnets?topic=subnets-getting-started&format=markdown), the whole subnet is routed to the overlay. ## Ingress private connectivity with gateway cluster {: #arch-pattern-nsx-t-private-connectivity-edge-gateway-cluster} Private ingress connectivity to NSX overlay is enabled through NAT or though using overlay tunnels. You can use IP addresses from the private portable subnet that is provisioned for T0 private uplinks for these use cases. With Juniper vSRX running on the [gateway cluster](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_orderinginstance-addl-clusters&format=markdown#vc_orderinginstance-addl-clusters-gate), you can alternatively route portable IP addresses to the T0 HA VIP and use the portable IP subnets in the overlay. ![Private ingress access to IBM Cloud NSX overlay with gateway cluster](../../images/arch-pattern-nsx-t-private-access-ingress-vsrx.svg "Private ingress access to IBM Cloud NSX overlay with gateway cluster"){: caption="Private ingress access to IBM Cloud NSX overlay with gateway cluster" caption-side="bottom"} The following list summarizes this architecture pattern deployment. 1. The automation deploys an NSX T0 Gateway in the NSX workload edge cluster. The T0 gateway provides connectivity to IBM Cloud private network. With gateway cluster, this uplink VLAN can be routed through the firewall, for example Juniper vSRX. 2. The automation deploys an example NSX overlay topology with a T1 Gateway and a few example segments attached both to the T1 and T0 Gateways. You can customize the topology based on your needs. 3. Workload T0 Gateway has a private uplink that is attached to the IBM Cloud private VLAN with three IP addresses, two for uplinks in edge 1 and edge 2 and one for HA VIP. Interfaces are configured with the network mask of the private portable subnet. The NSX T0 uplink does not support secondary IP addresses. {: note} 4. When you order a private portable subnet to a private VLAN that is routed by vSRX, BCR routes this subnet to the vSRX though its transit VLAN. 5. Instead of configuring the subnet as a secondary IP address in the interface in vSRX, you can route this subnet to the NSX T0 HA VIP. 6. You can then use this subnet in segments or specific IP addresses from it for NAT rules, load balancer VIPs, or VPN endpoints. ## Private connectivity through direct link {: #arch-pattern-nsx-t-private-connectivity-direct-link} Private connectivity for vCenter Server can use [IBM Cloud Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-dl-about&format=markdown) and tunneling. This solution is applicable for [NSX-based VCF for Classic - Automated instance](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_vcenterserveroverview&format=markdown), which is provisioned in IBM Cloud classic infrastructure. You can use Gateway Appliance or vCenter Server gateway cluster with Juniper vSRX or other device as part of the solution as an option. The tunnel is established between NSX T0 and a customer router routable through Direct Link. If vSRX or other third-party device is used in a gateway cluster, you can terminate the tunnel in these devices as well. In this case, NSX T0 advertises routes in the vSRX (or other third-party device) through BGP or Static Routes. For more information about this architecture pattern, see [Architecture pattern for using IPsec over Direct Link with a vCenter Server with NSX instance](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-arch-pattern-nsx-t-direct-link-ipsec&format=markdown). ## Private connectivity through transit gateway {: #arch-pattern-nsx-t-private-connectivity-transit-gateway} Hybrid cloud connectivity can be established by using [IBM Cloud® Transit Gateway](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-about&format=markdown). This solution is applicable for NSX-based VCF for Classic - Automated instance, which is provisioned in IBM Cloud classic infrastructure. This pattern requires a [gateway appliance](https://cloud.ibm.com/docs/gateway-appliance?topic=gateway-appliance-about&format=markdown#firewall) or [gateway cluster](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_orderinginstance-addl-clusters&format=markdown) with Juniper vSRX or other third-party device, which supports GRE. In this solution, a GRE tunnel is established between this device and Transit GW Router in a specific Zone. NSX T0 advertises routes through vSRX (or other device) to Transit Gateway. For more information about this architecture pattern, see [Architecture pattern for using Transit Gateway with a vCenter Server with NSX instance](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-arch-pattern-nsx-t-transit-gw&format=markdown). ## Related links {: #arch-pattern-nsx-t-private-connectivity-links} * [VMware vSphere overview](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vs_vsphereoverview&format=markdown) * [VMware NSX design](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-nsx-t-design&format=markdown)