For the pod deployment process to deploy your pod successfully into Microsoft Azure, you must configure your firewalls to allow Horizon Cloud to access the Domain Name Service (DNS) addresses it needs. In addition, your DNS must resolve specific names as described in this topic.

Important:

The pod deployment process uses a jump box VM. This jump box VM has ports and protocol requirements for the pod deployment process. See Ports and Protocols Required by the Jump Box During Pod Deployments and Pod Updates.

After a pod is successfully deployed, specific ports and protocols are required for ongoing Horizon Cloud operations. The specific ports and protocols required depends on whether the pod is at the manifest version for the September 2019 release, or is at a previous manifest version.

DNS Requirements for the Pod Deployment Process, Pod Upgrades, and Ongoing Operations

You must ensure the following DNS names are resolvable and reachable from the pod's management and tenant subnets using the specific ports and protocols as listed in the following table. Horizon Cloud uses specific outbound ports to securely download the pod software into your Microsoft Azure environment and so that the pod can connect back to the Horizon Cloud control plane. You must configure your network firewall such that Horizon Cloud has the ability to contact the DNS addresses on the ports that it requires. Otherwise, the pod deployment process will fail.

Table 1. Pod Deployment and Operations DNS Requirements
Source Pod Subnet Destination (DNS name) Port Protocol Purpose
Management One of the following, depending on which Horizon Cloud control plane is specified in your Horizon Cloud account:

cloud.horizon.vmware.com

cloud-eu-central-1.horizon.vmware.com

cloud-ap-southeast-2.horizon.vmware.com

443 TCP Horizon Cloud control plane.

cloud.horizon.vmware.com is in the United States

cloud-eu-central-1.horizon.vmware.com is in Europe

cloud-ap-southeast-2.horizon.vmware.com is in Australia

Management softwareupdate.vmware.com 443 TCP VMware software package server. Used for downloading updates of the agent-related software used in the system's image-related operations.
Management d1mes20qfad06k.cloudfront.net 443 TCP Horizon Cloud content delivery server. On the management subnet, this site is used for downloading the VHDs (virtual hard disks) for the pod's manager and Unified Access Gateway VMs.
Management packages.microsoft.com 443 and 11371 TCP Microsoft software package server. Used to securely download the Microsoft Azure Command Line Interface (CLI) software.
Management azure.archive.ubuntu.com 80 TCP Ubuntu software package server. Used by the pod's Linux-based VMs for Ubuntu operating system updates.
Management api.snapcraft.io 443 TCP Ubuntu software package server. Used by the pod's Linux-based VMs for Ubuntu operating system updates.
Management archive.ubuntu.com 80 TCP Ubuntu software package server. Used by the pod's Linux-based VMs for Ubuntu operating system updates.
Management changelogs.ubuntu.com 80 TCP Ubuntu software package server. Used by the pod's Linux-based VMs for tracking Ubuntu operating system updates.
Management security.ubuntu.com 80 TCP Ubuntu software package server. Used by the pod's Linux-based VMs for security-related Ubuntu operating system updates.
Management One of the following, depending on which Microsoft Azure cloud you are deploying your pod into:
  • Microsoft Azure (global): login.microsoftonline.com
  • Microsoft Azure Germany: login.microsoftonline.de
  • Microsoft Azure China: login.chinacloudapi.cn
  • Microsoft Azure US Government: login.microsoftonline.us
443 TCP This web address is generally used by applications to authenticate against Microsoft Azure services. For some descriptions in the Microsoft Azure documentation, see OAuth 2.0 authorization code flow, Azure Active Directory v2.0 and the OpenID Connect protocol, and National clouds. The National clouds topic describes how there are different Azure AD authentication endpoints for each Microsoft Azure national cloud.
Management One of the following, depending on which Microsoft Azure cloud you are deploying your pod into:
  • Microsoft Azure (global): management.azure.com
  • Microsoft Azure Germany: management.microsoftazure.de
  • Microsoft Azure China: management.chinacloudapi.cn
  • Microsoft Azure US Government: management.usgovcloudapi.net
443 TCP Used for pod API requests to the Microsoft Azure Resource Manager endpoints for using Microsoft Azure Resource Manager services. Microsoft Azure Resource Manager provides a consistent management layer to perform tasks through Azure PowerShell, Azure CLI, Azure portal, REST API, and client SDKs.
Management One of the following, depending on which Microsoft Azure cloud you are deploying your pod into:
  • Microsoft Azure (global): graph.windows.net
  • Microsoft Azure Germany: graph.cloudapi.de
  • Microsoft Azure China: graph.chinacloudapi.cn
  • Microsoft Azure US Government: graph.windows.net
443 TCP Access to the Azure Active Directory (Azure AD) Graph API, which is used for the pod's programmatic access to Azure Active Directory (Azure AD) through OData REST API endpoints.
Management One of the following, depending on which Microsoft Azure cloud you have deployed your pod into:
  • Microsoft Azure (global): *.blob.core.windows.net
  • Microsoft Azure Germany: *.blob.core.cloudapi.de
  • Microsoft Azure China: *.blob.core.chinacloudapi.cn
  • Microsoft Azure US Government: *.blob.core.usgovcloudapi.net
443 TCP Used for the pod's programmatic access to the Azure Blob Storage. Azure Blob Storage is a service for storing large amounts of unstructured object data, such as text or binary data.
Management One of the following, depending on which Microsoft Azure cloud you have deployed your pod into:
  • Microsoft Azure (global): *.vault.azure.net
  • Microsoft Azure Germany: *.vault.microsoftazure.de
  • Microsoft Azure China: *.vault.azure.cn
  • Microsoft Azure US Government: *.vault.usgovcloudapi.net
443 TCP Used for the pod's ability to programmatically work with the Azure Key Vault cloud service. Azure Key Vault is a cloud service that provides a secure store for secrets.
Management If your firewall or network security group (NSG) supports the use of service tags, one of the following:
  • Global Azure SQL service tag: Sql
  • Region-specific SQL service tag for the Azure region where the pod is deployed: Sql.region, such as Sql.WestUS.

If your firewall or network security group (NSG) does not support the use of service tags, you can use the hostname of the database. This name follows the pattern *.postgres.database.azure.com.

5432 TCP Used for pod communication to the Microsoft Azure PostgreSQL database server. Starting with the September 2019 release, pods that are newly deployed after that release date and pods that are upgraded to that release's manifest version are configured with a Microsoft Azure PostgreSQL database server.

For information about service tags in security groups, see the Microsoft Azure documentation topic at Service tags.

Tenant d1mes20qfad06k.cloudfront.net 443 TCP Horizon Cloud content delivery server. On the tenant subnet, this site is used by the system's automated Import Image process for downloading the installer for the agent-related software.
Tenant Depending on which regional Horizon Cloud control plane is specified in your Horizon Cloud account:
North America:
  • kinesis.us-east-1.amazonaws.com
  • query-prod-us-east-1.cms.vmware.com
Europe:
  • kinesis.eu-central-1.amazonaws.com
  • query-prod-eu-central-1.cms.vmware.com
Australia:
  • kinesis.ap-southeast-2.amazonaws.com
  • query-prod-ap-southeast-2.cms.vmware.com
443 TCP Cloud Monitoring Service (CMS)

Ports and Protocols Required by the Jump Box During Pod Deployments and Pod Updates

As described in Microsoft Azure Virtual Machine Requirements for a Horizon Cloud Pod in Microsoft Azure, a jump box VM is used in the initial creation of a pod and during subsequent software updates on the pod's environment. After a pod is created, the jump box VM is deleted. Then, when a pod is being updated, the jump box VM is re-created to run that update process and is deleted when the update has completed. Such updates include when a pod is edited to add a gateway.

Note: A pod that is either deployed new in Microsoft Azure starting with the September 2019 release or which is upgraded to the September 2019 release manifest level and has high availability enabled will have two manager VMs. The following paragraphs use the plural word VMs to indicate the jump box VM must communicate with all of the pod's manager VMs, whether the pod has only one or has two.

During those processes, that jump box VM communicates with the pod's manager VMs using SSH to the manager VMs' port 22. As a result, during the pod deployment process and pod update process, the requirement that communication between the jump box VM and the manager VMs' port 22 must be met. The manager VMs' port 22 must be allowed between the jump box VM as a source and the manager VMs as a destination. Because these VMs are assigned IP addresses dynamically, the network rule to allow this communication should use the management subnet CIDR as both the source and destination, with destination port 22, source port any, and protocol TCP.

Note: Ongoing pod operations do not require availability of port 22 on the pod's manager VMs. However, if you make a support request to VMware and the support team determines the way to debug that request is to deploy a jump box VM for SSH communication to your pod's manager VMs, then you will have to meet this port requirement during the time the VMware support team needs the port for debugging your issue. The VMware support team will inform you of any requirements, as appropriate for any support situation.