Lenzker’s #VMware #Horizon Guide (Implementation): Access Layer #NSX Load Balanced Unified Access Gateway

The following section shows you how to make use of VMware’s Unified Access Gateway (UAG) Appliance to give the enduser access into our virtual Desktop / Remote hosted Applications over an unsecure network like the Internet.

When we are creating this access we have multiple options.

  • Using a VPN to ‘tunnel’ into the secure cooperate network environment and connect further to the Horizon View environment.
  • Placing a Windows Server in the DMZ and installing/configuring the Horizon View Security Server and make it public accessible.
  • Placing the virtual Unified Access Gateway in the DMZ and installing/configuring the Horizon View Security Server and make it public accessible.

What is the / my recommendation nowadays? Go with the Unified Access Gateway. Why?

  1. It is a general opinion within Security experts that a Windows, even if it’s hardened, offers more attack potentials than a hardened minimal linux.
  2. Using the Windows based security server creates a 1:1 relationship between the Security Server and the Connection Server, therefore it takes away some access flexibility.
  3. The UAG is getting more and more features to integrate other solutions like specific Airwatch functionality
  4. You can make use of the UDP based Blast Extreme Protocol Adaptive Transport protocol that gives you a better remote/user experience even if you are connecting over a lossy network
  5. It is much easier to operate than the first Access Point versions VMware has made GA a few years ago ;-)

One important aspect of the UAG is that you need to know about the packet-flow between the Horizon Client and the Desktop. You will be dependant on the networking and security guys. Make sure you are able to clearly articulate the requirements and what is going to happen. If you can tell the flow, the other people will be able to help you much better.

Within this flow we have 2 phases. The first phase will handled by the Horizon Protocol 1 and is relevant for the initial authentication of the User against the broker while the Horizon Protocol 2 is used for the remote-protocol transport

Horizon Protocol 1:

The user enters a hostname at the Horizon Client and this starts the primary Horizon protocol. This is a control protocol for authentication authorization, and session management. The protocol uses XML structured messages over HTTPS… The load balancer routes this connection to one of the Unified Access Gateway appliances.

Horizon Protocol 2:

If this authentication attempt is successful, then one or more secondary connections are made from the Horizon Client. These secondary connections can include the following

  • HTTPS Tunnel used for encapsulating TCP protocols such as RDP, MMR/CDR and the client framework channel

  • Blast Extreme display protocol

  • PCoIP display protocol

Remember that even the Protocol 2 can do multiple connection (e.g. within PCOIP the initial connection is made on Port 4172 TCP while the actual remote-stream is done via Port 4172 UDP). The most important thing when design your solution and configuring your load-balancer and external URL is,  that the UAG where the 1. Horizon Protocol is handled must be the same where the 2. Horizon Protocol is send to. Session-Affinity or different external-Urls of the UAG is the key.

Unified Access Gateway

The UAG can be downloaded from the Horizon download portal and comes as an OVF file.

### Lab-Design Decision. For production use discuss implications of every Parameter

  • Version: 3.0
  • Connection to Desktop: Tunneled

Input required for installation / configuration:

  • Horizon Connection Server Certificate SHA-Thumbprint
  • Connection-Server / Load-Balancer FQDN
  • A vCenter user that has the permission to deploy an OVF
  • Pre-Configured

Dependencies for Installation:

  • Pre-Configured Network Protocol Profile on the datacenter level of the vCenter (Check my video to see how it works)
  • Public and Private IP-Addresses within the DMZ
  • A Minimum of one public accessible IP-address
  • Proper Configured Firewall policies between the Public network -> DMZ & DMZ -> Management Network & DMZ -> Desktop Network  (Use the Horizon Network diagram)
  • Clearance how many network adapters are used: 1-NIC, 2-NIC or 3-NIC mode


  • When you design a UAG topology within the network, make sure you understand the communication flow between Horizon Client and Horizon Desktop (I will talk a little about the primary / secondary Horizon Protocols when demonstrating my lab-setup)
  • Draw the Architecture on the whiteboard ;) Make sure how the primary and secondary Protocol will flow (Over the load-balancer? Direct to the Unified Access Gateway?) Are your components ready to handle the load and availability?
  • Make sure the Load Balancer balance the first and secondary protocol always to the same Unified Access Gateway
  • Create the vCenter Network Protocol profiles upfront within the vSphere Web Client -> datacenter -> configure
  • There is a good way to Powershell tools to deploy the Appliance. You can find the script and instructions here. You can also use the OVF-Import wizard over the vSphere Web Client. The only complexity here is to figure out which IP/DNS setting is relevant for which NIC (since this is not mentioned in the Wizard-Interface).
  • If you setup multiple Unified Access Gateways make use of the Configuration Export/Import feature to quickly set-up the basic settings. You might just need to adjust the settings for the external URL
  • If you change the SSL-Certificates of the Connection Server you need to do a change on the UAG Nodes as well
  • Do you want to know more about the communication flows? Play around in the lab and test different tunnel / ext-url settings. You can make use oft he NSX flow.
  • It doesn’t matter if you use the 1/2/3-nic mode. All can be secure / un-securely used. Make sure that the internet-facing firewall only gives access to the specific UAG on the required ports. The same counts for the datacenter facing firewall. The port diagram is your front.


The following illustrates a physical diagram of my lab environment network and the relevant components.

You are quite flexible how you setup your load-balancer as long as the 1. and the 2. Horizon protocol arrive at the same Unified Access Gateway. In my scenario I only have one IP-Address. Therefore from the Internet my UAG01 is reachable via port 20443 and 28443, while UAG 02 can be reached via 21443 / 29443. During the first Connection I get redirect to any UAG. If my credentials have been accepted the secondary protocol will address the external URL of the UAG which is either 20443/28443 or 21443 / 29443.


In this case I don’t really need to care about the persistent on the load-balancer since we only use the load-balancer in the initial phase.

Be a hero, don’t do it wrong :)


The following video shows you how the UAG can be installed.

The following video shows you how to set up the load-balancer in front of the UAG.

6 thoughts on “Lenzker’s #VMware #Horizon Guide (Implementation): Access Layer #NSX Load Balanced Unified Access Gateway

  • 27. September 2017 at 16:04

    should UAG02 have the port 28443 for blast in your diagram?

    • 27. September 2017 at 17:52

      yes..since I have only one public IP-Address I configured different blast ports on the two UAGs. Depending which one the load-balancer picks will be my new external-URL.

  • 15. October 2018 at 18:10

    Is the load balancer necessary? can I get by without setting a load balancer since I only have one UAG? tiny environment.

    • 17. October 2018 at 20:16

      You dont need a loadbalancer from a technical level. If you can live with the implication of having failed desktop connections in case of an UAG outage; feel free :).

      In any other case deploy 2 UAGs; deploy 2 Connection Server; activate a solid monitoring and be prepared to do some manual failovering (via DNS; etc).

  • 10. January 2019 at 9:23

    Why need configuring Network Protocol Profile ?

    • 10. January 2019 at 9:42

      That was a requirement in the older UAG versions. That requirement has been removed with the latest releases UAGs.

      The background story of the network profiles has to do with OVF / Appliance properties that have been used in the past. During / After setup/boot-up a script has been executed taking parameters defined on the vCenter level. Without the network profile information a proper network config would have not been possible.

      I didn’t liked this requirement and I am very happy that this has been removed :-) -> Decoupling for the win!


Leave a Reply

Your email address will not be published.

Time limit is exhausted. Please reload CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.