itopia Cloud VDI deployments can be used either as a self-contained, isolated VDI environment or as an extension of your existing networking and IT infrastructure. Furthermore, Cloud VDI is designed to provide end-users with secure connectivity over the public Internet without the need for VPNs; however, some organizations may wish to restrict user connectivity to only connect from their internal network.

This article will provide a general overview of the networking options available for Cloud VDI deployments, connectivity and firewall requirements for end-users, and alternative configuration options for common scenarios.

Within Google Cloud, the primary mechanism for defining network boundaries for VM instances is the virtual private cloud (VPC). VMs connected to the same VPC can communicate with one another, and routing rules on the VPC allow the VMs to communicate beyond the VPC.

Each VPC can then contain one or more subnets for each GCP region. VMs in each region are assigned to a subnet that is part of the VPC and are thus able to establish network connectivity.

When creating a new Cloud VDI deployment, you have several options for defining the VPC for your Cloud VDI VMs:

When creating a new VPC network, CAS will automatically perform all necessary configuration to secure your network and allow end-user connectivity. When you select an existing network or a shared VPC network, CAS may require you to run a number of commands using the gcloud utility to configure the shared network manually.

The Proxy Execution Service (PES) is an itopia-managed service that is responsible for executing management tasks in your Cloud VDI deployment. To ensure maximum security, CAS provisions a unique PES instance and a unique VPC network for each deployment; this infrastructure is managed by itopia and is not present within your Google Cloud project.

Regardless of which option you choose for your deployment's VPC network, CAS must create a VPC peering configuration between your deployment's VPC and the PES VPC. The VPC peering allows PES to communicate with your Cloud VDI VMs without traversing the public Internet.

As with the other settings of the VPC network, CAS will automatically configure the VPC peering when you create a new VPC network for your deployment. If you choose to create your deployment on a shared VPC, CAS will not have access to make these changes and will provide you with the gcloud commands to run for the peering configuration.

Some CAS deployments created prior to June 2020 did not use the Proxy Execution Service; instead, CAS managed these deployments using the Direct Administration model. In this model, CAS assigned each VM a public IP and sent management commands using these public interfaces.

For deployments that do not leverage the Proxy Execution Service, CAS management commands originate from the the following public IP addresses.

Regardless of the VPC type selected for the deployment, CAS requires several firewall rules to enable basic connectivity to the deployment. These firewall rules are automatically configured for new VPC networks and are included in the gcloud commands provided for existing and shared VPCs.

CAS deployments created after October 2020 rely exclusively on network tags to define their firewall rules; network tags are applied to individual VMs and allow targeted firewall rules without using specific IP addresses. CAS deployments prior to October 2020 used a combination on network tags and subnet-based rules.

The table below provides the network tags that are assigned to CAS deployment VMs. The majority of these tags are unused by CAS, but can be used by your administrators to create more granular firewall rules for restricting inter-server traffic as required by your organization's security and compliance policies.

The table below provides the network firewall rules that are created by CAS for standard deployments. All rules are allow rules, meaning traffic is permitted from the source to the target. In the table below, code is used to signify the deployment code; this will differ for each CAS deployment.

In addition to these rules, CAS deployments require inter-server network traffic on a number of standard ports used by Microsoft Windows; a comprehensive list of these ports is provided by Microsoft. For new VPC networks, CAS relies on the default firewall rule created by GCP that permit all traffic between all instances on the VPC network; this rule is typically named code-rule-default-allow-internal. For existing or shared VPC networks, administrators must ensure that firewall rules exist to permit inter-server traffic amongst CAS infrastructure servers and session hosts.

Depending on the type of deployment you create and the options you select, your environment will require a number of network ports to be available for inter-server traffic on your VPC network. This section will provide the network connectivity requirements for different configurations of CAS deployments.

The table below provides the standard set of ports that are required for typical interconnectivity of Windows servers and workstations in an Active Directory environment. This connectivity is required for all CAS deployments, regardless of other options selected.

If you create a CAS deployment that supports RDS and Windows 10 Collections, CAS will create infrastructure for Microsoft Remote Desktop Services (RDS). This infrastructure requires specific connectivity, as described in the table below.

In a standard CAS deployment, users connect to their Cloud VDI desktops over the public Internet using the Remote Desktop Protocol (RDP) over HTTPS. This connection is terminated at the RD Gateway server, which then establishes a separate RDP connection to their Session Host on the internal interfaces of the VPC network.

Users must be able to connect to the RD Gateway server using the standard HTTPS port TCP/443. No additional connectivity is required; however, the optional port UDP/3391 is used for some RDP data and may provide an enhanced user experience.

On most public or consumer networks, this connectivity is permitted by default. If your users are connecting from a corporate network, you may need to whitelist the IP addresses for your deployment's RD Gateway servers in each region (or the GCP load balancers, if you have deployed redundant RD Gateway server in each region).

If you do not wish to permit your users to connect over the public internet, it is possible to manually reconfigure the environment to only permit traffic from a private network. The high-level steps for this process are provided below; for detailed information, please contact itopia support.

Cloud VDI deployments require Microsoft Active Directory (AD) and can be configured with several different options to fulfill this requirement. Detailed information on this requirement is available in the article Active Directory in CAS Deployments.

Depending on the Active Directory option you choose for the deployment, connectivity requirements will differ for your environment.

Regardless of the Active Directory option selected for the deployment, the network ports for connectivity do not change; refer to the table in the Common Connectivity section of this article.

Deployments configured to use a new Active Directory domain typically do not require special configuration for AD connectivity. Active Directory domain controllers are created as VM instances on the deployment's VPC network, and the implicit firewall rules for VPC networks permit all necessary traffic between Cloud VDI servers and the domain controllers.

Deployments configured to use a new Google Managed AD domain typically do not require special configuration. As part of the provisioning process, Google Cloud will automatically create the necessary network peering and firewall exceptions to provide connectivity.

When configuring your CAS deployment to use an existing Active Directory domain without extending the domain, CAS will configure all CAS VM instances to use the existing domain controller IP addresses that you specify for their DNS and, subsequently, for all Active Directory access.

When using this AD model, itopia strongly recommends relying on Active Directory domain controllers that reside within the same GCP regions as your CAS deployment; using domain controllers that are hosted on-premises, co-hosted, or in a distant GCP region may result in poor performance and unexpected errors.

When using an existing Active Directory, all CAS VM instances must have connectivity to your existing domain controllers on all network ports listed above (see Common Connectivity).

When configuring your CAS deployment to extend an existing Active Directory domain, CAS will provision new domain controllers for the domain and will configure all CAS VM instances to use these domain controllers by default. The new domain controllers will be placed in a new AD site and a site link will be created with an existing AD site. To learn more about this process, please refer to Active Directory in CAS Deployments.

The new domain controllers will reside on the same VPC network as the CAS VM instances and should therefore have full connectivity to and from CAS infrastructure servers and session hosts.

For increased reliability, itopia recommends that deployments configured with Extended AD permit network traffic from all CAS VM instances to all domain controllers in the AD domain. However, if this is not possible due to security policies, most deployments can be configured to only permit network traffic between the new domain controllers (on the deployment's VPC network) to the existing domain controllers (on the on-premises network or the peered VPC network) in the AD site that is replicating with the CAS AD site. Note that in some cases, this connectivity may not be adequate and may result in errors or unpredictable behavior, and it may be necessary to permit traffic to and from all CAS VM instances.

When configuring your CAS deployment to use an Active Directory trust, CAS will provision a new AD domain (and forest) that will be used for the CAS VM instances; you can then configure a two-way Active Directory trust between this domain and your existing Active Directory domain to allow existing users to access their Cloud VDI desktops. To learn more about this process, please refer to Active Directory in CAS Deployments.

In a Trusted AD environment, it is required to permit network connectivity between all CAS VM instances and the domain controllers for your existing domain. RD Session Hosts and the RD Gateway both require direct access to the trusted domain controllers.