For successful end-to-end use of the service's features, you must ensure the Domain Name Service (DNS) names described in this documentation article are resolvable and reachable from the management and tenant subnets using the specific ports and protocols as indicated in this article's tables. The pod deployment process that instantiates a pod-manager-based pod into a Microsoft Azure subscription requires that the deployer-related appliances have access to specific DNS names over your selected VNet. Then after the pod is successfully instantiated in your subscription with its pod-related appliances up and running, various day-to-day service operations require network access to specific DNS names, as well as the pod update process for updating the pod's software when VMware makes the new software available to you. This article describes these DNS requirements.

Some Overarching Key Points

About these required DNS names
The Horizon Cloud pod deployer that automates the process to instantiate pod-manager-based pods and their associated gateways in your Microsoft Azure subscriptions requires network access to specific DNS addresses over those subscriptions' VNets. For the pod deployer to successfully instantiate the pod's components in your subscription, you must configure your firewalls to allow the key deployer-related appliances the network access they need to access those DNS addresses. Each DNS address's purpose is stated in the following tables. In addition to allowing network communication to those DNS addresses, your DNS configuration must resolve specific names as described in this article. When you choose the option to deploy the external gateway in its own VNet separate from the pod manager's VNet, that VNet's subnet must meet the same DNS requirements as the pod manager's VNet's management subnet.

The pod deployment process uses a jump box VM. This jump box VM has ports and protocol requirements for the pod deployment process, as well as for configuring settings for the pod's Unified Access Gateway VMs when you are deploying a Unified Access Gateway configuration for the pod. See Ports and Protocols Required by the Pod Jump Box During Pod Deployments and Pod Updates.

Deploying the external gateway into its own VNet also uses its own jump box VM, separate from the pod's. That jump box VM has its own ports and protocol requirements for the gateway deployment process. See When the External Gateway is Deployed in its Own VNet: Ports and Protocols Required by the External Gateway Configuration's Jump Box During Gateway Deployments and Updates.

Besides the pod deployer and its workflows, various service features require access to specific DNS addresses for those features to work end to end. Those DNS names are also provided in the following tables.

Some of these DNS names have a regional element to them.

The activation of Horizon Infrastructure Monitoring on a pod will automatically instantiate the Horizon Edge Virtual Appliance in the pod manager's VNet and management subnet. The Horizon Edge Virtual Appliance has its own DNS name requirements. Therefore, before you activate Horizon Infrastructure Monitoring on a pod, ensure you meet the DNS requirements of the Horizon Edge Virtual Appliance as indicated in the following tables.

As described in Tight Integration Within the VMware Ecosystem, you can use Horizon Cloud with other products available from the broader VMware ecosystem. Those other products might have additional DNS requirements. Such additional DNS requirements are not detailed here. For such DNS requirements, see the documentation set for the specific products that you will be integrating with your pod.

About ports and protocols after a pod is deployed, for ongoing service-related operations
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.

Regional Control Plane DNS Names

Your Welcome to Horizon Service email will indicate which regional control plane instance your tenant account was created in. Due to a known issue that existed when the welcome email was sent to you, the email you received might display the system string names used for the regions instead of human-friendly names. If you see a system string name in your welcome email, you can use the following table to relate what is shown in your email with the regional control plane DNS names.

Table 1. Regions in Your Welcome Email Mapped to Regional Control Plane DNS Names
Your welcome email says Regional DNS Name
USA cloud.horizon.vmware.com
EU_CENTRAL_1 or Europe cloud-eu-central-1.horizon.vmware.com
AP_SOUTHEAST_2 or Australia cloud-ap-southeast-2.horizon.vmware.com
PROD1_NORTHCENTRALUS2_CP1 or USA-2 cloud-us-2.horizon.vmware.com
PROD1_NORTHEUROPE_CP1 or Europe-2 cloud-eu-2.horizon.vmware.com
PROD1_AUSTRALIAEAST_CP1 or Australia-2 cloud-ap-2.horizon.vmware.com
Japan cloud-jp.horizon.vmware.com
UK cloud-uk.horizon.vmware.com
Europe-3 cloud-de.horizon.vmware.com

For the regional DNS addresses listed in the following tables for the Horizon Edge Virtual Appliance, those addresses use the same regions as the regional control plane DNS names.

DNS Requirements for the Overarching Pod Deployment Process, Pod Updates, Activation of Various Service Features, and Ongoing Operations

For successful end-to-end use of the service's features, you must ensure the following DNS names are resolvable and reachable from the management and tenant subnets using the specific ports and protocols as indicated in the following tables. Some of the service features that require the ability to reach specific DNS names are:

  • The pod deployer that automatically deploys of a pod-manager-based Horizon pod into your Microsoft Azure subscription
  • The pod update feature, that updates the pod's software to a more recent software version
  • The import-image process that uses the Import from Marketplace wizard
  • The agent-related features, such as automated agent update (AAU)
  • Universal Broker
  • Horizon Infrastructure Monitoring and its Horizon Edge Virtual Appliance
  • Features related to the Cloud Management Service (CMS)
Most especially for pod deployment, pod updates, and when activating the Horizon Infrastructure Monitoring on a pod
You must ensure the following DNS names are resolvable and reachable from the management and tenant subnets using the specific ports and protocols as indicated in the following tables. The appliances used in these workflows use specific outbound ports to securely download the software that these processes need into your Microsoft Azure environment. Those DNS names are also used so that the appropriate workflow-related appliances can communicate with the cloud control plane .

For new pod deployments, you must configure your network firewall, network security group (NSG) rules, and proxy servers such that the key deployment-related appliances have the ability to contact the DNS addresses on the ports that they requires. Otherwise, the pod deployment process will fail.

Activating Horizon Infrastructure Monitoring on a pod will instantiate the Horizon Edge Virtual Appliance into the same VNet and management subnet as that pod's pod-manager appliances. You must ensure the configuration your network firewall, NSG rules, and proxy servers allows theHorizon Edge Virtual Appliance to contact the DNS addresses on the ports that it requires. Otherwise, deployment of that appliance will fail.

When you are using the feature to deploy the external gateway into its own VNet
The management subnet in that VNet must meet the same DNS requirements as stated in the table below for the management subnet in the pod's VNet. The external gateway VNet's back-end subnet and DMZ subnet do not have specific DNS requirements.
When you are deploying the pod with either an external gateway, an internal gateway, or both
You must upload a certificate that the pod deployer will configure in those gateway configurations. If the certificate or certificates that you supply for this purpose use CRLs (Certificate Revocation Lists) or OCSP (Online Certificate Status Protocol) settings that refer to specific DNS names, then you must ensure outbound Internet access on the VNet to those DNS names is resolvable and reachable. During configuration of your supplied certificate in the Unified Access Gateway gateway configuration, the Unified Access Gateway software will reach out to those DNS names to check the certificate's revocation status. If those DNS names are not reachable, pod deployment will fail during its Connecting phase. These names are highly dependent on the CA that you used to obtain the certificates, and therefore are not in VMware's control.

DNS Requirements for New Pod Deployment, Pod Updates, and Service Operations that Apply on a Tenant-Wide Basis

The following table describes the DNS requirements for a new pod deployment, pod updates, and service operations that are applicable on a tenant-wide basis. For Horizon Infrastructure Monitoring activation and Horizon Edge Virtual Appliance DNS requirements, see the section after this one. Because the Horizon Infrastructure Monitoring feature is activated on a per-pod basis, its DNS requirements warrant their own descriptive table.

Attention: Starting in early 2021, as a result of an upgrade to the service's regional control plane instances, the d1mes20qfad06k.cloudfront.net DNS name is no longer required for any of the regional control plane instances. All of the regional control plane instances now use the hydra-softwarelib-cdn.azureedge.net DNS name. The following table's contents is aligned with that current reality.
Table 2. DNS Requirements for New Pod Deployment, Pod Updates, and Service Operations that Apply on a Tenant-Wide Basis
Subnet Source Destination (DNS name) Port Protocol Purpose
Management One of the following names, depending on which regional control plane instance is specified in your Horizon Cloud tenant account. The regional instance is set when the account is created, as described in Deployments and Onboarding to Horizon Cloud for Microsoft Azure and Horizon Pods.
  • cloud.horizon.vmware.com
  • cloud-us-2.horizon.vmware.com
  • cloud-eu-central-1.horizon.vmware.com
  • cloud-eu-2.horizon.vmware.com
  • cloud-ap-southeast-2.horizon.vmware.com
  • cloud-ap-2.horizon.vmware.com
  • cloud-jp.horizon.vmware.com
  • cloud-uk.horizon.vmware.com
  • cloud-de.horizon.vmware.com
443 TCP Regional control plane instance
  • United States: cloud.horizon.vmware.com, cloud-us-2.horizon.vmware.com
  • Europe: cloud-eu-central-1.horizon.vmware.com, cloud-eu-2.horizon.vmware.com
  • Asia Pacific: cloud-ap-southeast-2.horizon.vmware.com, cloud-ap-2.horizon.vmware.com
  • Japan: cloud-jp.horizon.vmware.com
  • United Kingdom: cloud-uk.horizon.vmware.com
  • Germany: cloud-de.horizon.vmware.com
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 hydra-softwarelib-cdn.azureedge.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. Also used for the VHD for the gateway connector VM, in the case where the external gateway is in its own VNet)
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-related 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 esm.ubuntu.com 80 TCP Ubuntu software package server. Used by the pod's Linux-based VMs for tracking security updates for high and critical CVEs (Common Vulnerabilities and Exposures) in the Ubuntu base OS and scale-out infrastructure.
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 updated 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.

Management One of the following names, depending on which regional control plane instance is specified in your Horizon Cloud tenant account. The regional instance is set when the account is created, as described in Deployments and Onboarding to Horizon Cloud for Microsoft Azure and Horizon Pods.
  • connector-azure-us.vmwarehorizon.com
  • connector-azure-eu.vmwarehorizon.com
  • connector-azure-aus.vmwarehorizon.com
  • connector-azure-jp.vmwarehorizon.com
  • connector-azure-uk.vmwarehorizon.com
  • connector-azure-de.vmwarehorizon.com

443 TCP Regional instance of the Universal Broker service
  • United States: connector-azure-us.vmwarehorizon.com
  • Europe: connector-azure-eu.vmwarehorizon.com
  • Australia: connector-azure-aus.vmwarehorizon.com
  • Japan: connector-azure-jp.vmwarehorizon.com
  • United Kingdom: connector-azure-uk.vmwarehorizon.com
  • Germany: connector-azure-de.vmwarehorizon.com
Management Depending on which regional control plane applies to your Horizon Cloud account:
  • North America: kinesis.us-east-1.amazonaws.com
  • Europe, Germany: kinesis.eu-central-1.amazonaws.com
  • Australia: kinesis.ap-southeast-2.amazonaws.com
  • Japan: kinesis.ap-northeast-1.amazonaws.com
  • United Kingdom: kinesis.eu-west-2.amazonaws.com
443 TCP Cloud Monitoring Service (CMS)
Tenant hydra-softwarelib-cdn.azureedge.net 443 TCP Horizon Cloud content delivery server. On the tenant subnet, this site is used by various system image-related processes, including processes involved in the system's automated Import Image from Marketplace workflow and agent pairing workflow.

Horizon Edge Virtual Appliance DNS Requirements

Activating Horizon Infrastructure Monitoring on a pod will instantiate the Linux-based Horizon Edge Virtual Appliance in your Microsoft Azure subscription. The Horizon Edge Virtual Appliance is deployed into the pod's subscription with a NIC on the pod's management subnet — the same management subnet as that pod's pod-manager appliances. In the following table, the listed purposes are in context of this virtual appliance.

Note: There are no DNS names with uk in this table like there are in the preceding table. As stated in the Release Notes, this Horizon Infrastructure Monitoring feature is currently in Limited Availability.
Table 3. Horizon Infrastructure Monitoring DNS Requirements
Subnet Source Destination (DNS name) Port/Protocol Purpose
Management
  • azure.archive.ubuntu.com
  • archive.ubuntu.com
  • changelogs.ubuntu.com
  • security.ubuntu.com
80 and 443 / TCP Ubuntu software package server. Used by the Linux-based appliance for Ubuntu operating system updates.
Management esm.ubuntu.com 80 / TCP Ubuntu software package server. Used by the Linux-based appliance for tracking security updates for high and critical CVEs (Common Vulnerabilities and Exposures) in the Ubuntu base OS and scale-out infrastructure.
Management
  • *.blob.core.windows.net
  • horizonedgeprod.azurecr.io
443 / TCP Used for programmatic access to the Azure Blob Storage.

Used to download the Docker images from those DNS addresses that the appliance's module requires.

Management

*.azure-devices.net, or one of the region-specific names below, depending on which regional control plane applies to your tenant account:

North America:

  • edgehubprodna.azure-devices.net

Europe:

  • edgehubprodeu.azure-devices.net

Australia:

  • edgehubprodap.azure-devices.net

Japan:

  • edgehubprodjp.azure-devices.net
443 / TCP Used to connect the appliance to the Horizon Cloud control plane, to download configurations for the appliance's module, and to update the appliance's module's runtime status.
Management
  • *.docker.com
  • *.docker.io
  • docker.io
  • cloud.google.com
  • gcr.io
  • dl.k8s.io
  • k8s.gcr.io
  • storage.googleapis.com
  • cloud.weave.works
  • packages.cloud.google.com
  • apt.kubernetes.io
443 / TCP Used to download Docker binaries and Kubernetes binaries that the appliance needs.
Management Depending on which regional control plane applies to your tenant account:

North America:

  • kinesis.us-east-1.amazonaws.com
  • sauron.horizon.vmware.com

Europe:

  • kinesis.eu-central-1.amazonaws.com
  • sauron-eu.horizon.vmware.com

Australia:

  • kinesis.ap-southeast-2.amazonaws.com
  • sauron-ap.horizon.vmware.com

Japan:

  • kinesis.ap-northeast-1.amazonaws.com
  • sauron-jp.horizon.vmware.com
443 / TCP Used to send the pod monitoring data collected by the appliance to the Horizon Cloud control plane.

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

As described in Microsoft Azure Virtual Machine Requirements for a Horizon Cloud Pod, 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 Unified Access Gateway configuration.

Note: A pod that is either deployed new in Microsoft Azure starting with the September 2019 release or which is updated 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.
  • The Unified Access Gateway VMs using HTTPS to those VMs' port 9443, in the case where a pod is deployed with, or edited to add, a Unified Access Gateway configuration. As a result, during the pod deployment process and pod update process, when the pod configuration includes Unified Access Gateway, the requirement that communication between the jump box VM and the Unified Access Gateway VMs' port 9443 must be met. The Unified Access GatewayVMs' port 9443 must be allowed between the jump box VM as a source and the Unified Access Gateway VMs as a destination.

Because these VMs are assigned IP addresses dynamically, the network rules 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.
  • The management subnet CIDR as both the source and destination, with destination port 9443, source port any, and protocol TCP, when a Unified Access Gateway configuration is involved.
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.

When the External Gateway is Deployed in its Own VNet: Ports and Protocols Required by the External Gateway Configuration's Jump Box During Gateway Deployments and Updates

As described in Microsoft Azure Virtual Machine Requirements for a Horizon Cloud Pod, a jump box VM is used in the initial creation of the external gateway in its own VNet and during subsequent software updates on that gateway. After the external gateway is created in its own VNet, the jump box VM is deleted. Then, when that external gateway 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 an external gateway in its own VNet.

During those processes, that jump box VM communicates with:

  • During those processes, that jump box VM communicates with the gateway connector VM using SSH to that connector VM's port 22. As a result, during the gateway deployment process and update process, the requirement that communication between the jump box VM and the connector VMs' port 22 must be met. The connector VMs' port 22 must be allowed between the jump box VM as a source and the connector VMs as a destination.
  • The Unified Access Gateway VMs using HTTPS to those VMs' port 9443. As a result, during the pod deployment process and pod update process, when the pod configuration includes Unified Access Gateway, the requirement that communication between the jump box VM and the Unified Access Gateway VMs' port 9443 must be met. The Unified Access GatewayVMs' port 9443 must be allowed between the jump box VM as a source and the Unified Access Gateway VMs as a destination.

Because these VMs are assigned IP addresses dynamically, the network rules 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.
  • The management subnet CIDR as both the source and destination, with destination port 9443, source port any, and protocol TCP.
Note: Ongoing pod operations do not require availability of port 22 on the gateway connector's VM. 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 that gateway's connector VM, 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.