I’ve had a several conversations over the past few weeks about how a VMware Horizon Client connects to a resource. Some of these exchanges were to help determine the best architecture, some were to understand the traffic flow and network ports, and others were to help in troubleshooting. I thought it would be worthwhile explaining how this works for internal and external connections, with the aid of some diagrams. Although I use VMware Horizon 7, including its Horizon Connection Server, most, if not all, of what is described here is applicable to VMware Horizon Cloud as well.
Primary and Secondary Protocols
First, it is important to understand that when a Horizon Client connects to a Horizon environment, several different protocols are used, and a successful connection consists of two phases.
The first phase of a connection is always the primary XML-API protocol over HTTPS, which provides authentication, authorization, and session management. Following successful authentication, a connection using one or more secondary protocols is then made to the resource.
If you want to explore the components and architecture of Horizon 7, see the Component Design: Horizon 7 Architecture section in the VMware Workspace ONE and VMware Horizon Reference Architecture.
With an internal connection, in the initial authentication phase, the connection is from the Horizon Client to the Connection Server. The secondary, protocol session then normally connects directly from the Horizon Client to the Horizon Agent.
Secondary protocol connections route through the Connection Server only when a gateway or tunnel—the Blast Secure Gateway, the PCoIP Secure Gateway, or the HTTPS Secure Tunnel—is enabled on the Connection Server. This configuration is less common because the protocol session is then tunneled through the Connection Servers, making it part of the ongoing session.
In most typical deployments, the only gateway service used on a Connection Server is the Blast Secure Gateway, to handle VMware HTML Access (web-based client) traffic. This is covered as a separate topic later in this post, in the section .
When load balancing Connection Servers, typically, only the initial XML-API connection (authentication, authorization, and session management) needs to be load balanced.
Because the secondary protocol connections go directly from the Horizon Client to the Horizon Agent, they are not load balanced.
If the connection is external, communication is typically through a VMware Unified Access Gateway (UAG) appliance. The initial authentication phase of a connection is from the Horizon Client to a Unified Access Gateway appliance and then to a Connection Server. The protocol session connection goes from the Horizon Client to the Unified Access Gateway and then to the Horizon Agent.
The Unified Access Gateway runs the following gateway services: the Blast Secure Gateway, the PCoIP Secure Gateway, and the HTTPS Secure Tunnel. Ensure that these gateway services are not also enabled on the Connection Server because this would cause a double-hop attempt of the protocol traffic, which is not supported and will result in failed connections.
This architecture also allows the same Connection Servers to be used for both external and internal connections.
When load balancing Horizon traffic to multiple UAG appliances, the initial XML-API connection (authentication, authorization, and session management) needs to be load balanced. The secondary Horizon protocols must be routed to the same UAG appliance to which the primary Horizon XML-API protocol was routed. This allows the UAG to authorize the secondary protocols based on the authenticated user session.
If the secondary protocol session is misrouted to a different Unified Access Gateway appliance from the primary protocol one, the session will not be authorized. The connection would therefore be dropped in the DMZ, and the protocol connection would fail. Misrouting secondary protocol sessions is a common problem if the load balancer is not configured correctly.
The load balancer affinity must ensure that XML-API connections made for the whole duration of a session (default maximum 10 hours) continue to be routed to the same UAG appliance.
Although the secondary protocol session must be routed to the same UAG appliance as was used for the primary XML-API connection, there is a choice of whether the secondary protocol session is routed through the load balancer or not. This normally depends on the capabilities of the load balancer.
For example, with an F5 BIG-IP Local Traffic Manager (LTM), primary and secondary protocol traffic goes the F5 LTM, and that ensures the correct routing of secondary protocol sessions by using source IP affinity. This has the advantage that there only needs to be a single public IP address. Where the load balancer does not have this capability, another option is to dedicate additional IP addresses for each UAG appliance so that the secondary protocol session can bypass the load balancer. See Load Balancing across VMware Unified Access Gateway Appliances.
When HTML Access is used, a web browser is used as the client to access a Horizon resource instead of an installed, native Horizon Client. One consideration is that the browser should trust the SSL certificate presented to it. In an external connection, the Unified Access Gateway runs the Blast Secure Gateway and will present the UAG certificate to the browser to verify identity.
With an internal connection, where the protocol session is normally direct from the client to the Horizon Agent, the agent side must present a trusted certificate to the browser. This presents some challenges.
- By default, Connection Server gives preference to sending the IP addresses, rather than host names, of desktop machines and RDSH servers to clients, which causes the certificate to be mismatched and not trusted. (This behavior can be changed to give preference to DNS names.)
- The desktop machines and RDSH servers must have a certificate installed that will be trusted by the browser on the client device. This behavior has traditionally led to the use of wildcard certificates.
A relatively new feature on Connection Server helps overcome these constraints and provides a more elegant solution. In Horizon Administrator, you can configure the use of the Blast Secure Gateway to provide secure access to remote desktops and applications only when HTML Access is used locally.
The Blast Extreme protocol traffic session is routed through the Connection Server and is presented with its SSL certificate. This removes the need to change the default way that the Connection Server sends the machine or RDSH server information to the host. It also means that there is no need to manage certificates on the desktop machines and RDSH servers.
With only the Enable the Blast Secure Gateway for HTML Access setting configured on the Connection Server, we get the following behavior:
- Internal HTML Access users that connect directly to the Connection Server have the Blast connection go through the Blast Secure Gateway on the Connection Server.
- Internal native Horizon Clients have the Blast connection go directly to the desktop.
- External users (HTML Access or native client) connecting through a UAG have the Blast connection go through the Blast Secure Gateway on the UAG. The connection then goes from the UAG appliance to the desktop and will not touch the Blast Secure Gateway on the Connection Server.
It also means a Connection Server can be shared for both internal and external connections, with the gateway services—the Blast Secure Gateway, the PCoIP Secure Gateway, and the HTTPS Secure Tunnel—running on the UAG for most use cases. Only internal HTML Access connections go through the Blast Secure Gateway on the Connection Server.
Now that you understand how a connection is made and how the traffic flows, you might want to look at the network ports that are used. The Network Ports in VMware Horizon 7 document has this detail, along with diagrams illustrating the traffic. It even has specific sections and diagrams on internal, external, and tunneled connections.
I would like to recognize the knowledge, assistance, and feedback given by Mark Benson, Senior Staff Engineer, EUC CTO Office, VMware.