Overview

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.

VPC Network

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:

• Create a new VPC network - This is the default behavior in the New Deployment Wizard and is the recommended option for most environments. CAS will create a new VPC in your Google Cloud project and will create subnets in each region that you include in your deployment; you may optionally specify the subnet IP ranges to use.
• Deploy to an existing VPC network - When configuring an Advanced deployment, you may select an existing VPC network in the same Google Cloud project or a VPC that has been shared with your project from another GCP project in the same organization. This option is useful if your organization has non-standard routing and your networking team has already configured a VPC network with the necessary routing rules.
• Deploy to a shared VPC network - When configuring an Advanced deployment, you may select a VPC that has been shared with your project from another GCP project in the same organization. This option is only recommended for organizations that have complex networking requirements and are familiar with shared VPC networking in Google Cloud.

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.

Proxy Execution Service

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.

Direct Administration

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.

35.243.149.230 40.69.191.179 40.69.185.248 52.165.132.218 52.165.234.167 52.173.32.122 52.173.34.204 52.173.39.249

52.173.88.150 52.173.193.86 52.173.244.161 52.176.2.229 52.176.99.160 96.65.182.97 96.65.182.98 96.65.182.99

96.65.182.100 96.65.182.101 167.71.181.176 168.61.154.160 168.61.155.254 168.61.157.210 168.61.152.85

Default Network Tags and Firewall Rules

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.

VM Role	GCP Network Tags
ALL VMs	cas-access winrm <server name>
Domain Controller	ad
File Server	fs
RD Broker	rdbrk
Session Host (RDS and Windows 10)	rdsh
RD Gateway	rdgw allow-access

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.

Name	Source	Target	Ports
code-rule-allow-access	0.0.0.0/0 (all sources)	tag: allow-access	TCP/443 UDP/3391
code-rule-cas-access	PES Network subnet If your deployment does not the Proxy Execution Service, this rule was configured to permit specific public IP addresses for CAS management systems; please refer to the section CAS Management IP Addresses	tag: cas-access	TCP/135 TCP/5985 TCP/5986

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.

Network Port Requirements

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.

Common Connectivity

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.

Source	Destination	Ports	Description
All CAS VM Instances	Active Directory Domain Controllers   In deployments using the Trusted AD model, these ports should also be enabled to the domain controllers in the trusted domain	TCP 53 88 135 139 389 445 464 636 3268-3269 9389 49152-65535 UDP 53 88 123 137 138 389 464 ICMP traffic	Minimum required connectivity for Active Directory functionality. Additional ports may be required for standard Windows Server functionality (such as management APIs [WMI, PowerShell, etc]); refer to https://support.microsoft.com/help/832017 for more information
All CAS VM Instances	All CAS VM Instances	TCP/135 TCP/1024-65535 TCP/446	Refer to https://support.microsoft.com/help/832017 to determine the network ports required for basic Windows Server functionality
RD Gateway Servers	Session Hosts (Windows Server/RDS and Windows 10)	TCP/3389 UDP/3389

Deployments with RDS Support

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.

Source	Target	Ports	Description
RD Connection Broker	RD Web Servers	TCP/5504
RD Web Servers	RD Connection Broker	TCP/5504	Centralized publishing
RD Connection Broker	RD Session Hosts	TCP/135 TCP/445 TCP/3389 TCP/49152-65535	RPC connectivity and session handoff
RD Session Hosts	RD Connection Broker	TCP/135 TCP/137-139 TCP/445 TCP/3389 TCP/49152-65535 UDP/137-139	RPC connectivity and host availability announcements
RD Licensing / RD Broker	Microsoft Licensing Clearinghouse (clearinghouse.one.microsoft.com)	TCP/443	License activation and authorization service for RDS. In CAS deployments, the RD Licensing role is installed on the first RD Broker server created (i.e., the VM with a name ending in brk001)

Required Connectivity for End-Users

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).

End-User Connectivity from a Private Network

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.

1. Connect your private network to the VPC network used by the CAS deployment. This can be achieved using a VPN or a Cloud Interconnect.
2. Remove firewall rules to prohibit connectivity to the RD Gateway servers from the public Internet
3. Create firewall rules to permit connectivity to the RD Gateway servers from your private network
4. Publish internal DNS records for your deployment to resolve to the private IP addresses of the RD Gateway servers. If your deployment is using the cloudvdi.net namespace, contact itopia support for assistance

Active Directory Connectivity Requirements

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.

New Domain - Microsoft Active Directory

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.

New Domain - Google Managed Service for Microsoft Active Directory

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.

Existing Active Directory

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).

Extended Active Directory

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.

Trusted Domain

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.