Using #VMware’s Unified Access Gateway (UAG) for internal #Horizon 7 connections – Design Discussion

Over the last months I gathered more and more experience about VMware’s secure Linux appliance  that allows secure access to a virtual Desktop (and more) over an unsecure network (e.g.) the Internet: Unified Access Gateway (UAG).

Keep in mind the UAG is not just a replacement for the old Windows based Security Sever, it is also  offering much more functionality (Edge Services for Airwatch / Workspace One, reverse proxy, 2nd-factor authentication integration, etc.).

There might be use cases where we want to design our horizon environment in a way that we use the UAGs not just for external unsecure access, but internally as well.

Examples:

  • Offering access to internal users coming from a not so trust-worthy site/location (including a second-factor authentication for those users). // Access restricted via Firewalls/ACLs
  • Constraints to always use tunneled connections (because of network-simplicity or security constraints).

How would we have dealt with this situation in an older environment including a Windows based Security Server? Since the Security Server required a 1:1 pairing between a Connection & a Security Server we would easily hit the maximum number of 7 Connection Server in case that we want to offer multiple accesses from different locations.

Let’s assume the following scenario. We need to offer access to 4 types of users:

  • Access from the internal head-quarters (HQ) – All virtual Desktops are hosted within the HQs datacenter.
  • Access from a branch-office that must use RSA-token
  • Access from a branch-office in a different not-so-well-trusted country that is only allowed to communicate with a single Endpoint within the (HQ) network
  • Access from the internet for a specific User group

The following logical design would be a solution using windows based security server

Why is that architectural approach not so beneficial?

  • Availability: The maximum number of Connection Server that can be used (master & replica) is 7. We are not able to fulfill the required scenarios without hitting that number and have full redundancy for specific access components
  • Maintainability: All Connection Server are Windows based. If the Connections are tunneled (which is required in our scenario) we would have more user struggle when patching the Connection Servers underlay windows (Since the connection will drop). In this solution design 9 Windows Machines must be managed in a careful way to minimize user impact

How could we achieve the same functionality with the Unified Access Gateways?

What is the advantage of this design approach?

  • Availability: 2 Windows Connection Servers only. Since we are not constraint by a 1:1 relationship between the UAG and the Connection Server we are much more flexible and can create full redundancy for all access ways.
  • Maintainability: All tunnels between the end users Endpoint and their respective Desktop is tunneled over the UAG. The reboot and patching of the Windows based connection server can be done completely seamless for the end-user. So we don’t need to patch the hardened linux appliance? For sure we do. But the process around here is much easier. Quiesce the UAG within the respective administration interface. Existing sessions will remain, new sessions will not be created over that UAG, the load-balancer will get a different https response which will remove it out of the load-balancing. Next step: Deploy a new UAG with the newer version, import the configuration file, add it to the load balancer application pool and voila. That’s it!!!!
  • Security: The UAG is a hardened Linux appliance. I hated the discussions with the infosec guys in the past about placing a Windows Server in the DMZ.

Remember that you can tag the UAG as an internal or external access component. If it is configured as external you can use the restriction functionality within Horizon (e.g. only specific member of an AD-Group can access Desktops over the Internet or User Environment Manager (different in-guest security policies based on the access components).

I know those are very extreme /rare examples, but the key message should be clear. Using those stateless Unified Access Gateways gives us much much more flexibility in how to design and operate the virtual Desktop and Application access layer.

8 thoughts on “Using #VMware’s Unified Access Gateway (UAG) for internal #Horizon 7 connections – Design Discussion

  • 15. May 2018 at 13:45
    Permalink

    Hi,

    Is there any problem in having UAGs and connection servers in different sites? as the communication between UAGs and connection servers will be over the WAN, is there any latency requirements on this communication? Would performance be ok for users?

    Thanks,
    Javier

    Reply
    • 1. June 2018 at 3:00
      Permalink

      UAG and Horizon connection server should be in the same location, UAG and connection servers connected over WAN is not supported use case by VMware.

      Reply
      • 2. May 2019 at 20:17
        Permalink

        How come we can then deploy UAG in the Cloud to access Internal Horizon installations?
        Latency between the cloud and internal networks is high.

  • 13. May 2019 at 21:33
    Permalink

    We are considering using UAG’s to proxy all connections, effectively eliminating an “internal vs external” setup entirely. It appears in your scenario here you still have internal connections running directly to the load balancer and bypassing the UAG’s. What are your thoughts on our proposed setup? Would you see any caveats in this approach? Thanks.

    Reply
    • 17. May 2019 at 8:29
      Permalink

      In most internal scenarios you would make a direct connection between the endpoint and the virtual desktop which means after phase 1 of the authentication all communication is done directly.

      In an internal scenario I have described where you still want to tunnel the connections, you could either do everything against the load-balancer or against the UAGs by defining the external urls properly (either against the LB or against the dedicated UAG-instance). Both has pro and cons (and I have excluded using the new UAG as a load balancer here)

      External URL to Load Balancer: No endpoint awareness of the UAGs required (less firewall rules), easier scale-out afterwards
      External URL to UAG: No logical SPOF of the Load Balancer

      In my experience when dealing with any kind of remote sites, it is more complicated to open up corporate firewalls to too many internal components (like the UAG)

      Reply
  • 17. July 2020 at 14:03
    Permalink

    How do you handle this scenario if your internal domain is different than your external domain? Especially when it comes to certificates? The UAGs want a unified certificate thumbprint when you have two connection servers behind a load balancer. Or are you SSL offloading on the load balancer for the connection server?

    Reply
    • 11. September 2020 at 10:55
      Permalink

      Not sure if I get the question right, but as far as I remember you can put multiple thumbprints of the connection server into the UAG.

      In most environment we utilize one ca signed certificate [with all hostnames as SAN] for all connection servers. Therefore there is only one thumbprint in use.

      Reply

Leave a Reply to Bill Long Cancel 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.