Networking requirements
Google Cloud VMware Engine offers a private cloud environment that's accessible to users and applications from on-premises environments, enterprise-managed devices, and Google Cloud services like Virtual Private Cloud (VPC). To establish connectivity between VMware Engine private clouds and other networks, you use networking services such as Cloud VPN and Cloud Interconnect.
Some network services require user-specified address ranges to enable functionality. To help you plan your deployment, this page lists networking requirements and their associated features.
VMware Engine private cloud connectivity
The connection from your VPC network to a VMware Engine differs based on whether you use standard or legacy networks.
Standard VMware Engine networks
The connection from your VPC network to a Standard VMware Engine network uses VPC Network Peering.
Legacy VMware Engine networks
The connection from your VPC network to a Legacy VMware Engine network uses private services access. To access your workload virtual machines (VMs) from an on-premises network or from your VPC network, set up private services access from your VPC network to your VMware Engine network.
Global address resolution using Cloud DNS
If you want global address resolution using Cloud DNS, enable the Cloud DNS API. You must complete Cloud DNS setup before you create your private cloud.
CIDR requirements and restrictions
VMware Engine uses set address ranges for services like hosting management appliances and deploying HCX networks. Some address ranges are mandatory and others depend on the services that you plan to deploy.
You must reserve address ranges such that they won't overlap with any of your on-premises subnets, VPC network subnets, or planned workload subnets.
Additionally, your workload VMs and vSphere/vSAN subnet CIDR range must not overlap with any IP addresses in the following ranges:
- 127.0.0.0/8
- 224.0.0.0/4
- 0.0.0.0/8
- 169.254.0.0/16
- 198.18.0.0/15
- 240.0.0.0/4
vSphere/vSAN subnets CIDR range
VMware Engine deploys management components of a private cloud in the vSphere/vSAN subnets CIDR range that you provide during private cloud creation. IP addresses in this range are reserved for private cloud infrastructure, and can't be used for workload VMs. The CIDR range prefix must be between /24 and /20.
Subnets CIDR range division versions
Private clouds created after November 2022 adhere to IP address layout (IP Plan) version 2.0 subnet allocations. Almost all private clouds created before November 2022 adhere to IP Plan version 1.0 subnet allocations.
To find out which version your private cloud adheres to, complete the following steps:
- Access the Google Cloud console.
- From the main menu, click Private clouds.
- Click on the private cloud you want to review.
- Look for IP Plan version to find out what version this private cloud uses.
The version number is displayed under IP Plan version.
vSphere/vSAN subnets CIDR range size
The size of your vSphere/vSAN subnets CIDR range affects the maximum size of your private cloud. The following table shows the maximum number of nodes you can have, based on the size of the vSphere/vSAN subnets CIDR range.
| Specified vSphere/vSAN subnets CIDR prefix | Maximum number of nodes (IP Plan version 1.0) | Maximum number of nodes (IP Plan version 2.0) |
|---|---|---|
| /24 | 26 | 10 |
| /23 | 58 | 20 |
| /22 | 118 | 40 |
| /21 | 220 | 90 |
| /20 | N/A | 200 |
When selecting your CIDR range prefix, consider the node limits on resources in a private cloud. For example, CIDR range prefixes of /24 and /23 don't support the maximum number of nodes available to a private cloud. Alternatively, CIDR range prefixes of /20 support more than the current maximum number of nodes available to a private cloud.
Example management network CIDR range division
The vSphere/vSAN subnets CIDR range you specify is divided into multiple subnets. The following tables show examples of the breakdown for allowed prefixes. The first set of examples use 192.168.0.0 as the CIDR range for IP Plan version 1.0, and the second set of examples use 10.0.0.0 for IP Plan version 2.0.
| Function | Subnet mask/prefix (IP Plan version 1.0) | |||
|---|---|---|---|---|
| vSphere/vSAN subnets CIDR range | 192.168.0.0/21 | 192.168.0.0/22 | 192.168.0.0/23 | 192.168.0.0/24 |
| System management | 192.168.0.0/24 | 192.168.0.0/24 | 192.168.0.0/25 | 192.168.0.0/26 |
| vMotion | 192.168.1.0/24 | 192.168.1.0/25 | 192.168.0.128/26 | 192.168.0.64/27 |
| vSAN | 192.168.2.0/24 | 192.168.1.128/25 | 192.168.0.192/26 | 192.168.0.96/27 |
| NSX-T host transport | 192.168.4.0/23 | 192.168.2.0/24 | 192.168.1.0/25 | 192.168.0.128/26 |
| NSX-T edge transport | 192.168.7.208/28 | 192.168.3.208/28 | 192.168.1.208/28 | 192.168.0.208/28 |
| NSX-T edge uplink1 | 192.168.7.224/28 | 192.168.3.224/28 | 192.168.1.224/28 | 192.168.0.224/28 |
| NSX-T edge uplink2 | 192.168.7.240/28 | 192.168.3.240/28 | 192.168.1.240/28 | 192.168.0.240/28 |
| Function | Subnet mask/prefix (IP Plan version 2.0) | |||||
|---|---|---|---|---|---|---|
| vSphere/vSAN subnets CIDR range | 10.0.0.0/20 | 10.0.0.0/21 | 10.0.0.0/22 | 10.0.0.0/23 | 10.0.0.0/24 | |
| System management | 10.0.0.0/22 | 10.0.0.0/23 | 10.0.0.0/24 | 10.0.0.0/25 | 10.0.0.0/26 | |
| vMotion | 10.0.4.0/24 | 10.0.2.0/25 | 10.0.1.0/26 | 10.0.0.128/27 | 10.0.0.64/28 | |
| vSAN | 10.0.5.0/24 | 10.0.2.128/25 | 10.0.1.64/26 | 10.0.0.160/27 | 10.0.0.80/28 | |
| NSX-T transport | 10.0.6.0/23 | 10.0.3.0/24 | 10.0.1.128/25 | 10.0.0.192/26 | 10.0.0.128/27 | |
| HCX uplink | 10.0.11.128/25 | 10.0.6.0/26 | 10.0.3.32/27 | 10.0.1.144/28 | 10.0.0.216/29 | |
| NSX-T edge uplink1 | 10.0.8.0/28 | 10.0.4.0/28 | 10.0.2.0/28 | 10.0.1.0/28 | 10.0.0.160/29 | |
| NSX-T edge uplink2 | 10.0.8.16/28 | 10.0.4.16/28 | 10.0.2.16/28 | 10.0.1.16/28 | 10.0.0.168/29 | |
| NSX-T edge uplink3 | 10.0.8.32/28 | 10.0.4.32/28 | 10.0.2.32/28 | 10.0.1.32/28 | 10.0.0.176/29 | |
| NSX-T edge uplink4 | 10.0.8.48/28 | 10.0.4.48/28 | 10.0.2.48/28 | 10.0.1.48/28 | 10.0.0.184/29 | |
HCX and NSX-T Edge Scaling (IP Plan version 2.0 only)
| Specified vSphere/vSAN subnets CIDR prefix | Maximum remote HCX sites | Maximum HCX Network Extension appliances | Maximum NSX-T Edge VMs |
|---|---|---|---|
| /24 | 2 | 1 | 2 |
| /23 | 4 | 2 | 4 |
| /22 | 14 | 8 | 8 |
| /21 | 25 | 32 | 8 |
| /20 | 25 | 64 | 8 |
HCX deployment network CIDR range (IP Plan version 1.0 only)
In IP Plan version 1.0, HCX was not integrated into the vSphere/vSAN subnets CIDR range. When you created a private cloud, you could optionally have VMware Engine install HCX on the private cloud by specifying a network CIDR range for use by HCX components. The CIDR range prefix was /26 or /27.
VMware Engine divided the network that you provided into three subnets:
- HCX management: Used for installation of HCX Manager.
- HCX vMotion: Used for vMotion of VMs between your on-premises environment and VMware Engine private cloud.
- HCX WANUplink: Used for establishing the tunnel between your on-premises environment and VMware Engine private cloud.
Example HCX CIDR range breakdown
The HCX deployment CIDR range you specify is divided into multiple subnets. The following table shows examples of the breakdown for allowed prefixes. The examples use 192.168.1.0 as the CIDR range.
| Function | Subnet mask/prefix | |||
|---|---|---|---|---|
| HCX Deployment Network CIDR range | 192.168.1.0/26 | 192.168.1.64/26 | 192.168.1.0/27 | 192.168.1.32/27 |
| HCX Manager | 192.168.1.13 | 192.168.1.77 | 192.168.1.13 | 192.168.1.45 |
Private services access to VMware Engine
The following table describes the address range requirement for private connection to Google Cloud services.
| Name/purpose | Description | CIDR prefix |
|---|---|---|
| Assigned address range | Address range to be used for private connection to Google Cloud services including VMware Engine. | /24 or larger |
Edge networking services provided by VMware Engine
The following table describes the address range requirement for edge networking services provides by VMware Engine.
| Name/purpose | Description | CIDR prefix |
|---|---|---|
| Edge Services CIDR | Required if optional edge services, such as internet access and public IP, are enabled, on a per region basis. | /26 |
Accessing Private/Restricted Google APIs
By default both Private 199.36.153.8/30 and Restricted 199.36.153.4/30 CIDRs
are advertised into the VMware Engine network to support direct access to Google
services. The Private CIDR 199.36.153.8/30 can be retracted upon configuration
of VPC Service Controls.
Firewall port requirements
You can set up a connection from your on-premises network to your private cloud by using site-to-site VPN or Dedicated Interconnect. Use the connection to access your VMware private cloud vCenter and any workloads you run in the private cloud.
You can control what ports are opened on the connection by using a firewall in your on-premises network. This section lists common application port requirements. For port requirements of any other applications, see the documentation for that application.
For more information about ports used for VMware components, see VMware Ports and Protocols.
Ports required for accessing vCenter
To access vCenter Server and NSX-T Manager in your private cloud, open the following ports on the on-premises firewall:
| Port | Source | Destination | Purpose |
|---|---|---|---|
| 53 (UDP) | On-premises DNS servers | Private cloud DNS servers | Required for forwarding DNS lookup of gve.goog to private cloud DNS servers from on-premises network. |
| 53 (UDP) | Private cloud DNS servers | On-premises DNS servers | Required for forwarding DNS lookup of on-premises domain names from private cloud vCenter to on-premises DNS servers. |
| 80 (TCP) | On-premises network | Private cloud management network | Required for redirecting vCenter URL from HTTP to HTTPS. |
| 443 (TCP) | On-premises network | Private cloud management network | Required for accessing vCenter and NSX-T Manager from on-premises network. |
| 8000 (TCP) | On-premises network | Private cloud management network | Required for vMotion of virtual machines (VMs) from on-premises to private cloud. |
| 8000 (TCP) | Private cloud management network | On-premises network | Required for vMotion of VMs from private cloud to on-premises. |
Common ports required for accessing workload VMs
To access workload VMs running on your private cloud, you must open ports on your on-premises firewall. The following table lists common ports. For any application-specific port requirements, see to the application documentation.
| Port | Source | Destination | Purpose |
|---|---|---|---|
| 22 (TCP) | On-premises network | Private cloud workload network | Secure shell access to Linux VMs running on private cloud. |
| 3389 (TCP) | On-premises network | Private cloud workload network | Remote desktop to Windows Server VMs running on private cloud. |
| 80 (TCP) | On-premises network | Private cloud workload network | Access any web servers deployed on VMs running on private cloud. |
| 443 (TCP) | On-premises network | Private cloud workload network | Access any secure web servers deployed on VMs running on private cloud. |
| 389 (TCP/UDP) | Private cloud workload network | On-premises Active Directory network | Join Windows Server workload VMs to on-premises Active Directory domain. |
| 53 (UDP) | Private cloud workload network | On-premises Active Directory network | DNS service access for workload VMs to on-premises DNS servers. |
Ports required for using on-premises Active Directory as an identity source
For a list of ports required to configure your on-premises Active Directory as an identity source on the private cloud vCenter, see Configuring authentication using Active Directory.