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.
Before you begin
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project : Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
- Create a project
: To create a project, you need the Project Creator role
(
roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.createpermission. Learn how to grant roles .
If you're using an existing project for this guide, verify that you have the permissions required to complete this guide . If you created a new project, then you already have the required permissions.
Verify that billing is enabled for your Google Cloud project .
Enable the Cloud DNS and VMware Engine APIs.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM
role ( roles/serviceusage.serviceUsageAdmin
), which
contains the serviceusage.services.enable
permission. Learn how to grant
roles
.
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project : Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
- Create a project
: To create a project, you need the Project Creator role
(
roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.createpermission. Learn how to grant roles .
If you're using an existing project for this guide, verify that you have the permissions required to complete this guide . If you created a new project, then you already have the required permissions.
Verify that billing is enabled for your Google Cloud project .
Enable the Cloud DNS and VMware Engine APIs.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM
role ( roles/serviceusage.serviceUsageAdmin
), which
contains the serviceusage.services.enable
permission. Learn how to grant
roles
.
Required roles
To get the permissions that
you need to complete this quickstart,
ask your administrator to grant you the VMware Engine Viewer
( roles/vmwareengine.vmwareengineViewer
)
IAM role on the project.
For more information about granting roles, see Manage access to projects, folders, and organizations
.
You might also be able to get the required permissions through custom roles or other predefined roles .
VMware Engine private cloud connectivity
For an overview of private cloud networking, see Private cloud networking for VMware Engine .
The connection from your VPC network to a Standard VMware Engine network uses VPC Network Peering .
Global address resolution using Cloud DNS
If you want global address resolution using Cloud DNS , 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 rangethat 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:
-
In the Google Cloud console, go to the Private cloudspage.
-
Click Select a projectand then select the organization, folder, or project where the private cloud is located.
-
Click the private cloud you want to review.
-
Look for IP Plan versionto 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
|
200 | 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.
| 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 host transport
|
192.168.4.0/23 | 192.168.2.0/24 | 192.168.1.0/25 | 192.168.0.128/26 |
|
NSX edge transport
|
192.168.7.208/28 | 192.168.3.208/28 | 192.168.1.208/28 | 192.168.0.208/28 |
|
NSX edge uplink1
|
192.168.7.224/28 | 192.168.3.224/28 | 192.168.1.224/28 | 192.168.0.224/28 |
|
NSX edge uplink2
|
192.168.7.240/28 | 192.168.3.240/28 | 192.168.1.240/28 | 192.168.0.240/28 |
| 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 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 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 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 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 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 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 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.
| 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 |
For more information on setting up private service access, see Set up private service access .
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 and 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 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 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 .
