Navigation
- Change Log
- Overview
- PowerShell Deploy Script Method – both upgrade and new
- vSphere Client Deploy OVF method – Upgrade Existing, or Deploy New
- Web-based Admin Interface
- Add UAG to Horizon Console
- Monitor Sessions
- Logs and Troubleshooting
- Load Balancing
- UAG Authentication – SAML, RADIUS
- Other UAG Configurations – High Availability, Network Settings, System Settings
💡 = Recently Updated
Change Log
- 2024 July 27 – updated Import OVF section for UAG 2406
- 2024 Jan 31 – SHA-1 thumbprint no longer supported. Replace with SHA-256 thumbprint (fingerprint).
- 2021 Sep 30 – Horizon Edge configuration – added instructions to disable CORS to fix HTML Access in Horizon 2106 and newer.
Overview
Unified Access Gateway provides remote connectivity to internal Horizon Agent machines. For an explanation of how this works (i.e., traffic flow), see Understanding Horizon Connections at Omnissa Tech Zone.
Unified Access Gateway (formerly known as Access Point) is a replacement for Horizon Security Servers. Advantages include:
- You don’t need to build extra Connection Servers just for pairing. However, you might want extra Horizon Connection Servers so you can filter pools based on tags.
- Between Unified Access Gateway and Horizon Connection Servers you only need TCP 443. No need for IPSec or 4001 or the other ports. You still need 4172, 22443, etc. to the View Agents.
- No need to enable Gateway/Tunnel on the internal Horizon Connection Servers.
- Additional security with DMZ authentication. Some of the Authentication methods supported on Unified Access Gateway are RSA SecurID, RADIUS, CAC/certificates, etc.
However:
- It’s Linux. You can deploy and configure the appliance without any Linux skills. But you might need some Linux skills during troubleshooting.
Horizon View Security Server has been removed from Horizon 2006 (aka Horizon 8).
- Some of the newer Blast Extreme functionality only works in Unified Access Gateway. See Configure the Blast Secure Gateway at Omnissa Docs.
More information at VMware Blog Post Technical Introduction to VMware Unified Access Gateway for Horizon Secure Remote Access.
Horizon Compatibility – Refer to the interoperability matrix to determine which version of Unified Access Gateway is compatible with your version of Horizon.
- The latest version of UAG is 2406.
- You usually want the Non-FIPS version.
- Then download the PowerShell deployment scripts on the same UAG download page.
- You usually want the Non-FIPS version.
- If you are running an ESB version of Horizon, then make sure you run the ESB version of Unified Access Gateway. Get it from the same page as your Horizon download.
- Use the Select Version drop-down to select the version of Horizon you have deployed.
- Then open the downloads for the edition that you are entitled to: Standard, Advanced, or Enterprise.
- Scroll down the page to see the Unified Access Gateway downloads. You usually want the Non-FIPS version.
- Then download the PowerShell deployment scripts on the same UAG download page.
- Use the Select Version drop-down to select the version of Horizon you have deployed.
Firewall
Omnissa Tech Zone Blast Extreme Display Protocol in Horizon, and Firewall Rules for DMZ-Based Unified Access Gateway Appliances at Omnissa Docs.
Open these ports from any device on the Internet to the Unified Access Gateway Load Balancer VIP:
- TCP and UDP 443
- TCP and UDP 4172. UDP 4172 must be opened in both directions. (PCoIP)
- TCP and UDP 8443 (for HTML Blast)
Open these ports from the Unified Access Gateways to internal:
- TCP 443 to internal Connection Servers (through a load balancer)
- TCP and UDP 4172 (PCoIP) to all internal Horizon View Agents. UDP 4172 must be opened in both directions.
- TCP 32111 (USB Redirection) to all internal Horizon View Agents.
- TCP and UDP 22443 (Blast Extreme) to all internal Horizon View Agents.
- TCP 9427 (MMR and CDR) to all internal Horizon View Agents.
Open these ports from any internal administrator workstations to the Unified Access Gateway appliance IPs:
- TCP 9443 (REST API)
- TCP 80/443 (Edge Gateway)
PowerShell Deploy Script
Omnissa Docs Using PowerShell to Deploy VMware Unified Access Gateway. The script runs OVF Tool to deploy and configure Unified Access Gateway. The PowerShell script is updated as newer versions of Unified Access Gateways are released. This is the recommended method of deploying Unified Access Gateway.
If you prefer to use vSphere Client to Deploy the OVF file, skip ahead to Upgrade or Deploy.
The PowerShell deployment script is downloadable from the UAG download page.
The PowerShell deploy script requires the OVF Tool:
- Download ovftool from Broadcom.
- If OVF Tool is already installed, then you’ll have to uninstall the old version before you can upgrade it.
- On the machine where you will run the UAG Deploy script, install VMware-ovftool-…-win.x86_64.msi.
- In the Welcome to the VMware OVF Tool Setup Wizard page, click Next.
- In the End-User License Agreement page, check the box next to I accept the terms and click Next.
- In the Destination Folder page, click Next.
- In the Ready to install VMware OVF Tool page, click Install.
- In the Completed the VMware OVF Tool Setup Wizard page, click Finish.
Create or Edit a UAG .ini configuration file:
- Extract the downloaded uagdeploy PowerShell scripts for your version of Unified Access Gateway.
- If you have an existing UAG appliance, then you can download an INI of the configuration from the UAG Administrator page.
- Or copy and edit one of the downloaded .ini files, like uag2-advanced.ini.
- Or copy and edit one of the downloaded .ini files, like uag2-advanced.ini.
- A full explanation of all configuration settings can be found at Using PowerShell to Deploy Unified Access Gateway at Omnissa Docs.
- For any value that has spaces, do not include quotes in the .ini file. The script adds the quotes automatically.
- The name setting specifies the name of the virtual machine in vCenter. If this VM name already exists in vCenter, then OVF Tool will delete the existing VM and replace it.
- Add a uagName setting and specify a friendly name. You’ll later add this name to Horizon Console so you can view the health of the UAG appliance in Horizon Console.
- You can optionally enable SSH on the appliance by adding sshEnabled=true.
- For the source setting, enter the full path to the UAG .ova file.
- For the target setting, leave PASSWORD in upper case. Don’t enter an actual password. OVF Tool will instead prompt you for the password.
- For the target setting, specify a cluster name instead of a host. If spaces, there’s no need for quotes. For example:
target=vi://admin@corp.local:PASSWORD@vcenter02.corp.local/Datacenter/host/Cluster 1
- Specify the exact datastore name for the UAG appliance.
- Optionally uncomment the diskMode setting.
- For a onenic configuration (recommended), set the netInternet, netManagementNetwork, and netBackendNetwork settings to the same port group name.
- Multiple dns servers are space delimited.
- For pfxCerts, UNC paths don’t work. Make sure you enter a local path (e.g. C:\). OVA Source File can be UNC, but the .pfx file must be local.
- There’s no need to enter the .pfx password in the .ini file since the uagdeploy.ps1 script will prompt you for the password.
- proxyDestinationUrl should point to the internal load balancer for the Horizon Connection Servers.
- For proxyDestinationUrlThumbprints, paste in the sha256 or higher thumbprint of the Horizon Connection Server certificate in the format shown.
- If your Horizon Connection Servers each have different certificates, then you can include multiple thumbprints (comma separated).
- Make sure there’s no hidden character between sha256 and the beginning of the thumbprint. Or you can just paste the thumbprint without specifying sha256. Note: sha1 is no longer supported. Edge and Chrome can show sha256 certificate fingerprint.
- Change the ExternalUrl entries to an externally-resolvable DNS name and a public IP address. For multiple UAGs, the FQDNs and public IP address should resolve to the load balancer. Note: your load balancer must support persistence across multiple port numbers (443, 8443, 4172).
When you run the PowerShell script, if the UAG appliance already exists, then the PowerShell script will replace the existing appliance. There’s no need to power off the old appliance since the OVF tool will do that for you.
- Open an elevated PowerShell prompt.
- Paste in the path to the uagdeploy.ps1 file. If there are quotes around the path, then add a & to the beginning of the line so PowerShell executes the path instead of just echoing the string.
- Add the -iniFile argument and enter the path to the .ini file that you modified. Press <Enter> to run the script.
- You’ll be prompted to enter the root password for the UAG appliance. Make sure the password meets password complexity requirements.
- You’ll be prompted to enter the admin password for the UAG appliance. Make sure the password meets password complexity requirements.
- For CEIP, enter yes or no.
- For .pfx files, you’ll be prompted to enter the password for the .pfx file. Note: the .pfx file must be local, not UNC.
- OVF Tool will prompt you for the vCenter password. Special characters in the vCenter password must be encoded. Use a URL encoder tool (e.g., https://www.urlencoder.org/) to encode the password. Then paste the encoded password when prompted by the ovftool. The UAG passwords do not need encoding, but the vCenter password does.
- The deploy script will display the IP address of the powered on UAG appliance.
- Review settings in the UAG admin interface.
- Add the new UAG appliance to Horizon Console.
Upgrade
To upgrade from an older appliance, you delete the old appliance and import the new one. Before deleting the older appliance, export your settings:
- Login to the UAG at https://<Your_UAG_IP>:9443/admin/index.html.
- In the Configure Manually section, click Select.
- Scroll down to the Support Settings section, and then click the JSON button next to Export Unified Access Gateway Settings.
- Note: the exported JSON file does not include the UAG certificate, so you’ll also need the .pfx file. If RADIUS is configured, then during import you’ll be prompted to enter the RADIUS secret.
Deploy New
Horizon Compatibility – Refer to the interoperability matrix to determine which version of Unified Access Gateway is compatible with your version of Horizon.
- The latest version of UAG is 2406.
- You usually want the Non-FIPS version.
- You usually want the Non-FIPS version.
- If you are running an ESB version of Horizon, then make sure you run the ESB version of Unified Access Gateway. Get it from the same page as your Horizon download.
- Use the Select Version drop-down to select the version of Horizon you have deployed.
- Then open the downloads for the edition that you are entitled to: Standard, Advanced, or Enterprise.
- Scroll down the page to see the Unified Access Gateway downloads. You usually want the Non-FIPS version.
- Use the Select Version drop-down to select the version of Horizon you have deployed.
To deploy the Unified Access Gateway using VMware vSphere Client:
- If vSphere Client, right-click a cluster, and click Deploy OVF Template.
- Select Local File and click Upload Files. In the Open window, browse to the downloaded euc-unified-access-gateway.ova file, and click Next.
- In the Select a name and folder page, give the machine a name, and click Next.
- In the Review Details page, click Next.
- In the Select configuration page, select a Deployment Configuration. See Network Segments at Unified Access Gateway Architecture at Omnissa Tech Zone. Click Next.
- In the Select storage page, select a datastore, select a disk format, and click Next.
- In the Select networks page, even if you select Single NIC, the OVF deployment wizard asks you for multiple NICs. UAG typically goes in the DMZ.
- In the Customize template page, select STATICV4, and scroll down.
- In the NIC1 (eth0) IPv4 address field, enter the NIC1 (eth0) IPv4 address. Scroll down.
- Enter DNS addresses, Gateway, and Subnet Mask. Scroll down.
- Scroll down and enter more IP info.
- Scroll down.
- Enter a Unified Gateway Appliance Name.
- Scroll down.
- UAG 2207 and newer let you specify the local root username.
- Enter passwords.
- UAG 20.12 (2012) and newer let you specify Password Policy settings when deploying the OVF.
- UAG 20.12 (2012) and newer let you specify Password Policy settings when deploying the OVF.
- Scroll down and enter the password for the admin user.
- UAG 2207 and newer have an adminreset command if you mess up the admin interface login. There’s also an adminpwd command to reset the password.
- UAG 2207 and newer have an option to enable DISA STIG compliance, usually on the FIPS version of UAG.
- There’s a checkbox for Enable SSH.
- In UAG 3.9 and newer, there’s an option to login using a SSH key/pair instead of a password.
- Newer versions of UAG have more SSH options.
- UAG 2207 adds Commands to Run on First Boot or Every Boot.
- Click Next.
- In the Ready to complete page, click Finish.
UAG Admin Interface
- Power on the Unified Access Gateway appliance.
- Point your browser to https://My_UAG_IP:9443/admin/index.html and login as admin. It might take a few minutes before the admin page is accessible.
- UAG 2207 and newer have an adminreset command if you mess up the admin interface login. There’s also an adminpwd command to reset the password.
Import Settings
- If you have previously exported settings, you can import it now by clicking Select in the Import Settings section.
- Browse to the previously exported UAG_Settings.json file and then click Import. Note that this json file might have old settings, like old ciphers. Review the file to ensure you’re not importing legacy configurations. If the .json file has a SHA-1 thumbprint, then edit the file and replace it with SHA-256 thumbprint (fingerprint).
- It should say UAG settings imported successfully. If you don’t see this, then your .json file probably has a SHA-1 thumbprint.
- Press <F5> on your keyboard to refresh the browser.
- The .json file does not include the certificate so you’ll have to do that separately. In the Admin console, in the Advanced Settings section, click TLS Server Certificate Settings.
- In the top row labelled Apply certificate to, select Internet interface.
- Change the drop-down for Certificate Type to PFX.
- In the row Upload PFX, click Select and browse to your PFX file.
- In the Password field, enter the PFX password and then click Save.
Configure Horizon Settings
- To manually configure the appliance, under Configure Manually, click Select.
- Click the slider for Edge Service Settings.
- Click the slider for Enable Horizon.
- As you fill in these fields, hover over the information icon to see the syntax.
- The Connection Server URL should point to the internal load balanced DNS name (URL) for your internal Connection Servers.
- For the Connection Server URL Thumbprint, get the thumbprint from the internal Horizon certificate. Point your browser to the internal Horizon Connection Server FQDN (load balanced) and click the padlock icon to open the certificate.
- On the Details tab, copy the SHA-256 Fingerprint. Note that SHA-1 thumbprint is no longer supported.
- For the Connection Server URL Thumbprint, get the thumbprint from the internal Horizon certificate. Point your browser to the internal Horizon Connection Server FQDN (load balanced) and click the padlock icon to open the certificate.
- In the Proxy Destination URL Thumb Prints field, type in
sha256=
and paste the certificate thumbprint. - At the beginning of the Thumbprint field, immediately after the equals sign, there might be a hidden character. Press the arrow keys on the keyboard to find it. Then delete the hidden character.
- Enable the three PCOIP, Blast, and Tunnel Gateways and perform the following configurations:
- For PCOIP External URL, enter the external IP and
:4172
. The IP should point to your external load balancer that’s load balancing UDP 4172 and TCP 4172 to multiple Unified Access Gateways. - For Blast External URL, enter https://<FQDN>:8443 (e.g. https://view.corp.com:8443). This FQDN should resolve to your external load balancer that’s load balancing UDP 8443 and TCP 8443 to multiple Unified Access Gateways.
- You could change the Blast port to 443 but this would increase CPU utilization on UAG. See Omnissa 78419 Unified Access Gateway (UAG) high CPU utilization.
- Link: Troubleshooting Blast at Omnissa Discussions
- For Enable UDP Tunnel Server, enable the setting.
- For Tunnel External URL, enter https://<FQDN>:443 (e.g., https://view.corp.com:443). This FQDN should resolve to your external load balancer that’s load balancing TCP 443 to multiple Unified Access Gateways.
- The external load balancer must be capable of using the same persistence across multiple port numbers. On NetScaler, this feature is called Persistency Group. On F5, the feature is called Match Across.
- For PCOIP External URL, enter the external IP and
- Then click More.
- Unified Access Gateway has a default list of paths it will forward to the Horizon Connection Server. You can edit the Proxy Pattern and add
|/downloads(.*)
to the list so that users can also download Horizon Clients that are stored on your Horizon Connection Servers as detailed elsewhere at carlstalhood.com. Make sure you click Save at least once so it saves the default Proxy Pattern. Then go back in and add|/downloads(.*)
to the end of the Proxy Pattern but inside the last parentheses. In UAG 2406, the default Proxy Pattern looks something like below:
(/|/view-client(.*)|/portal(.*)|/appblast(.*)|/iwa(.*)|/downloads(.*))
- Scroll down and click Save when done.
- If you click the arrow next to Horizon Settings, then it shows you the status of the Edge services.
- If all you see is Not Configured, then refresh your browser and then click the Refresh Status icon.
- If all you see is Not Configured, then refresh your browser and then click the Refresh Status icon.
- In your Horizon Connection Servers, the Secure Gateways (e.g. PCoIP Gateway) should be disabled.
- Go to Horizon Console.
- Expand Settings and click Servers.
- On the right, switch to the tab named Connection Servers.
- Highlight your Connection Servers and click Edit.
- Then uncheck or disable all three Tunnels/Gateways.
- HTML Access probably won’t work through Unified Access Gateway. You’ll probably see the message Failed to connect to the Connection Server.
- To fix this, configure on each Connection Server the file C:\Program Files\VMware\VMware View\Server\sslgateway\conf\locked.properties to disable Origin Check (checkOrigin=false) or configure the Connection Server’s locked.properties with the UAG addresses. Also see 2144768 Accessing the Horizon View Administrator page displays a blank error window in Horizon 7.
- Horizon 2106 and newer enable CORS by default so you’ll need to either disable CORS by adding enableCORS=false to C:\Program Files\VMware\VMware View\Server\sslgateway\conf\locked.properties, or configure the portalHost entries in locked.properties as detailed at 85801 Cross-Origin Resource Sharing (CORS) with Horizon 8 and loadbalanced HTML5 access.
- After modifying the locked.properties file, restart the VMware Horizon View Security Gateway Component service.
Add UAG to Horizon Console
In Horizon 7.7 and newer, you can add UAG 3.4 and newer to Horizon Console so you can check its status in the Dashboard.
- In UAG Admin console, under Advanced Settings, click the gear icon next to System Configuration.
- At the top of the page, change the UAG Name to a friendly name. You’ll use this case-sensitive name later.
- Click Save at the bottom of the page.
- In Horizon Console, on the left, expand Settings and click Servers.
- On the right, switch to the tab named Gateways.
- Click the Register button.
- In the Gateway Name field, enter the case-sensitive friendly name you specified earlier, and then click OK.
See status of UAG appliances:
- Use a Horizon Client to connect through a Unified Access Gateway. Horizon Console only detects the UAG status for active sessions.
- In Horizon Console 7.10 and newer, to see the status of the UAG appliances, on the top left, expand Monitor and click Dashboard.
- In the top-left block named System Health, click VIEW.
- With Components highlighted on the left, on the right, switch to the tab named Gateway Servers.
- This tab shows the status of the UAG appliances, including its version. If you don’t see this info, then make sure you launch a session through the UAG.
To see the Gateway that users are connected to:
- In Horizon Console 7.10 or newer, go to Monitor > Sessions.
- Search for a session and notice the Security Gateway column. It might take a few minutes for it to fill in.
UAG Authentication
SAML is configured in UAG 3.8 and newer in the Identity Bridging Settings section.
- Upload Identity Provider Metadata.
- Then in UAG Admin > Edge Service Settings > Horizon Settings > More (bottom of page), you can set Auth Methods (near top of page) to SAML only, which requires True SSO implementation, or SAML and Passthrough, which requires two logins: one to IdP, and one to Horizon.
- For complete True SSO instructions, see https://www.carlstalhood.com/vmware-horizon-true-sso-uag-saml/.
- For Okta and True SSO, see Enabling SAML 2.0 Authentication for Horizon with Unified Access Gateway and Okta: VMware Horizon Operational Tutorial at Omnissa Tech Zone.
- For Azure MFA, see Sean Massey Integrating Microsoft Azure MFA with VMware Unified Access Gateway 3.8.
For RADIUS authentication:
- Enable the Authentication Settings section and configure the settings as appropriate for your requirements. See Configuring Authentication in DMZ at VMware Docs.
- When configuring RADIUS, if you click More, there’s a field for Login page passphrase hint.
- When configuring RADIUS, if you click More, there’s a field for Login page passphrase hint.
- Then in Edge Service Settings > Horizon Settings > More (bottom of page), you can set Auth Methods (near top of page) to RADIUS.
- If you scroll down the Horizon Settings page, you’ll see additional fields for RADIUS.
- In UAG 3.8 and newer, Passcode label field can be customized for MFA providers like Duo.
- If your RADIUS is doing Active Directory authentication (e.g. Microsoft Network Policy Server with Azure MFA), then Enable Windows SSO so the user isn’t prompted twice for the password.
Other UAG Configurations
- UAG 3.8 and newer shows when the admin password expires in Account Settings in the Advanced Settings section.
- Ciphers are configured under Advanced Settings > System Configuration.
- The default ciphers in UAG 2406 are the following and include support for TLS 1.3.
TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- In UAG older than 2103, Syslog is also configured here. In UAG 2103 and newer, Syslog is in a different menu as described below.
- At the bottom of the System Configuration page are several settings for SNMP, DNS, and NTP.
- UAG 20.12 (2012) and newer support SNMPv3.
- UAG 3.10 and newer have Admin Disclaimer Text.
- You can add NTP Servers.
- The default ciphers in UAG 2406 are the following and include support for TLS 1.3.
- Session Timeout is configured in System Configuration. It defaults to 10 hours.
- UAG 3.6 and newer let you add static routes to each NIC.
- Click Network Settings.
- Click the gear icon next to a NIC.
- Click IPv4 Configuration to expand it and then configure IPv4 Static Routes.
- Click Network Settings.
- UAG 2103 and newer have a different menu item for Syslog Server Settings.
- You can specify up to two Syslog servers.
- You can include System Messages.
- UAG 2207 supports MQTT when adding Syslog servers.
- UAG 20.09 (2009) and newer can automatically install patches/updates when the appliance reboots.
- In the Advanced Settings section, click Appliance Updates Settings.
- For Apply Updates Scheme, select an option. Click Save.
- In the Advanced Settings section, click Appliance Updates Settings.
- UAG supports High Availability Settings.
- With the High Availability Virtual IP address, you might not need load balancing of the UAG appliances. See Unified Access Gateway High Availability at Omnissa Docs.
- The High Availability feature requires three IP addresses and three DNS names:
- One IP/FQDN for the High Availability Virtual IP.
- And one IP/FQDN for each appliance/node.
- The Horizon Edge Gateways should be set to node-specific IP addresses and node-specific DNS names. Each appliance is set to a different IP/FQDN.
- The Virtual IP (and its DNS name) is only used for the High Availability configuration.
- The YouTube video High Availability on VMware Unified Access Gateway Feature Walk-through explains the High Availability architecture.
- The High Availability feature requires three IP addresses and three DNS names:
- Set the Mode to ENABLED.
- Enter a new Virtual IP Address which is active on both appliances.
- Enter a unique Group ID between 1 and 255 for the subnet.
- Click Save.
- On the second appliance, configure the exact same High Availability Settings.
- With the High Availability Virtual IP address, you might not need load balancing of the UAG appliances. See Unified Access Gateway High Availability at Omnissa Docs.
- To upload a valid certificate, scroll down to the Advanced Settings section, and next to TLS Server Certificate Settings, click the gear icon.
- In Unified Access Gateway 2312 and newer, click Edit in the Internet section.
- In Unified Access Gateway 3.2 and newer, you can apply the uploaded certificate to Internet Interface, Admin Interface, or both.
- In Unified Access Gateway 3.0 and newer, change the Certificate Type to PFX, browse to a PFX file, and then enter the password. This PFX file certificate must match the Public FQDN (load balanced) for Unified Access Gateway. If your load balancer is terminating SSL, then the certificate on the UAG must be identical to the certificate on the load balancer.
- Leave the Alias field blank.
- Click Save.
- If you changed the Admin Interface certificate, then you will be prompted to close the browser window and re-open it.
- In Unified Access Gateway 2312 and newer, click Edit in the Internet section.
- Or, you can upload a PEM certificate/key (this is the only option in older UAG). Next to Private Key, click the Select link.
- Browse to a PEM keyfile. If not running Unified Access Gateway 3.0 or newer, then certificates created on Windows (PFX files) must be converted to PEM before they can be used with Unified Access Gateway. You can use openssl commands to perform this conversion. The private key should be unencrypted.
- Browse to a PEM certificate file (Base-64) that contains the server certificate, and any intermediate certificates. The server certificate is on top, the intermediate certificates are below it. The server certificate must match the public FQDN (load balanced) for the Unified Access Gateway.
- Click Save when done.
- Browse to a PEM keyfile. If not running Unified Access Gateway 3.0 or newer, then certificates created on Windows (PFX files) must be converted to PEM before they can be used with Unified Access Gateway. You can use openssl commands to perform this conversion. The private key should be unencrypted.
- UAG 3.1 and newer have an Endpoint Compliance Check feature. The feature requires an OPSWAT subscription. Newer versions of UAG can deploy the OPSWAT agent. It’s pass/fail. See Configure OPSWAT as the Endpoint Compliance Check Provider for Horizon at VMware Docs.
- UAG 3.9 and newer let you upload the Opswat Endpoint Compliance on-demand agent executables. Horizon Client downloads the executables from UAG and runs them. See Upload OPSWAT MetaAccess on-demand agent Software on Unified Access Gateway at VMware Docs.
- In UAG 20.09 and newer, Outbound Proxy Settings can be configured to allow UAG to contact the Opswat servers when checking for device compliance.
- UAG 3.9 and newer let you upload the Opswat Endpoint Compliance on-demand agent executables. Horizon Client downloads the executables from UAG and runs them. See Upload OPSWAT MetaAccess on-demand agent Software on Unified Access Gateway at VMware Docs.
- Scroll down to Support Settings and click the icon next to Export Unified Access Gateway Settings to save the settings to a JSON file. If you need to rebuild your Unified Access Gateway, simply import the the JSON file.
- The exported JSON file does not include the UAG certificate, so you’ll also need the .pfx file.
- The exported JSON file does not include the UAG certificate, so you’ll also need the .pfx file.
- If you point your browser to the Unified Access Gateway external URL, you should see the Horizon Connection Server portal page. Horizon Clients should also work to the Unified Access Gateway URL.
Monitor Sessions
In UAG 3.4 and newer, in the UAG Admin interface,
- At the top of the page, next to Edge Service Settings, you can see the number of Active Sessions on this appliance.
- At the bottom of the page, under Support Settings, click Edge Service Session Statistics to see more details.
In older versions of UAG, to see existing Horizon connections going through UAG, point your browser to https://uag-hostname-or-ip-addr:9443/rest/v1/monitor/stats.
Logs and Troubleshooting
You can download logs from the Admin Interface by clicking the icon next to Log Archive.
You can also review the logs at /opt/vmware/gateway/logs
. You can less
these logs from the appliance console.
Or you can point your browser to https://MyApplianceIP:9443/rest/v1/monitor/support-archive. This will download a .zip file with all of the logfiles. Much easier to read in a GUI text editor.
For initial configuration problems, check out admin.log.
For Horizon View brokering problems, check out esmanager.log.
By default, tcpdump is not installed on UAG. To install it, login to the console and run /etc/vmware/gss-support/install.sh
- More info at Justin Johnson Troubleshooting Port Connectivity For Horizon’s Unified Access Gateway 3.2 Using Curl And Tcpdump
Load Balancing
If NetScaler, see https://www.carlstalhood.com/vmware-horizon-unified-access-gateway-load-balancing-citrix-adc/ load balance Unified Access Gateways.
To help with load balancing affinity, UAG 3.8 and newer can redirect the load balanced DNS name to a node-specific DNS name. This is configured in Edge Service Settings > Horizon Settings > More (bottom of page).
Related Pages
- Back to Omnissa Horizon 8
I have a question about UAG HA mode. I understand it uses it’s own internal load balancer. Is it possible to use HA mode in a DMZ scenario that requires NAT. I can’t assign public IPs directly to the UAGs so they would have to be DMZ IPs that have public IPs natted to them.
That’s not a problem.
Clients connect to the VIP, which can be NAT’d. When launching a session, the UAG sends back its node-specific IP address (PCoIP) or FQDN (Blast), both of which can be NAT. For two UAG nodes, you’ll need three public IPs.
awesome thank you!
Hi ,
Thanks for your valuable information.
I managed to setup the test UAG and it can communicate with my horizon connection server (all green)
However
-When I use the UAG.xxxx.local address to access via the web browser, an error “Failed to resolve proxying route for request” comes up after enter my login name and select relevant applications. From the address it shows “https://myfqdn/r/7B9C13E8-82E9-4C51-846D-5D12D07614EA/certAccept.html?numPages=1
– When I use Horizon Client to connect the same address , an error “SSl connection was shutdown while reading” shown
Are there anything I can troubleshoot further?
In addition I’d checked all the VM’s time sync and all required ports required were open (or allowed) and the connection between UAG and connection shows green in both admin coles
Thanks .
Is https://myfqdn the address of your Connection Server instead of the UAG? Is the Blast Secure Gateway disabled on the Connection Server?
Are you load balancing UAG? If so, does the load balancer have the same certificate as the UAG?
Hi
I’m not using any load balancer , just 1-1 connection between UAG and connection server
For the first query, that ‘myfqdn’ is my connection server one, and the blast secure gateway (and others) had been disabled as per your article
I’m having a problem that I can’t seem to figure out. I have UAGs and Horizon 7. It works fine when users use the Horizon client. The problem is https users. They get a login for RSA and then AD. Then they get an error, can’t make a connection. and go back to the first page. They login a second time and it works fine, they get in. I have check origins set to false. I have the outside url set to balanced host. I’m stumped and support is trying hard. Any ideas why this loop back is happening?
Hi. I got problem. I have view and uag installed (view.domain.com and uag.domain.com). After I install uag everything was fine except html access from uag, so I desided to fix it with locked file and reboot system. Now with “Do not use security gateway” option users get error “the connection to the remote computer ended”. So they can only access view via uag. Any way I can fix this?
Hello Carl,
You are articles very detailed, thanks. I have a question, I am running a UAG version 3.8 and I have radius enabled and configured properly. This is working today. I wanted to setup an additional authentication and I don’t have the options for radius and unauthenticated. UAG 3.8 setup on the DMZ.
3.9 seems to have it as an option. https://docs.vmware.com/en/Unified-Access-Gateway/3.9/com.vmware.uag-39-deploy-config.doc/GUID-1B8665A2-485E-4471-954E-56DB9BA540E9.html
Hi Carl….we are deploying a new VDI-UAG environment and plan to use the 3 NIC deployment. I can’t find anything online that shows the 3NIC set up steps. Is the 3 NIC worth it? Or do you know of any tutorials for it? Thanks in advance!
3 NIC is for dedicated management network and two double-hop DMZ. I don’t recommend connecting the UAG to both DMZ and Internal since that would bypass the DMZ-to-internal firewall.
The UAG can only have a single default route. With multiple NICs, default gateway is the client gateway (Internet facing) and then you’d add static routes for internal networks through a router/firewall that can reach internal.
Thanks so much for your response. Looks like we will go with single NIC.
Hi Carl,
2fa using Radius on connection server 8.2 is getting disabled every time I click Ok I am using smspasscode as second factor authentication. When I click ok I do not see any error however when I check the settings again for 2fa it is disabled. I am using the default ports 1812 & 1813. It was working fine on connection server 7.10.
Please help me in fixing the issue.
Thanks for a great resource!
I just found out that the UAG –> Horizon Settings –> Disable HTML Access … is not working at all. Users are still able to click Launch from Browser in Workspace ONE Access, hit the UAG (passthrough auth) do SSO and it’ll still load the desktop in the browser.
Running UAG 21.03
Prefer not to tinker with HTML Access client restrictions (the replacement for the HTML Access toggle in the pool itself) on the Connection Server, because internally the HTML Access comes in handy, but externally i don’t want the option.
Any ideas?
Same here, using Versions below, no solution in sight.
Comments welcome, pointing to possible reasons.
I was guessing for it to be a compatibility issue, but no. Actually, it doesn´t seem to exist anyhow:
https://interopmatrix.vmware.com/Interoperability?col=326,5976,5603,5460,5091,4920,4160&row=569,5588,5355
Horizon 2106 with UAG
Name: euc-unified-access-gateway-21.06.2.0-18528989_OVF10.ova
Release Date: 2021-08-31
Build Number: 18528989
Hi
Appreciate your advise. I”m new to UAG and want to know if multiple connection servers can use one UAG. This is without a load balancer, is this possible?
On each UAG you can enter a single Connection Server address. I’m not sure if DNS round robin would work or not.
Yes they can, but if it goes down you’ll end up with none. Why not deploy two and leverage UAG HA, which doesn’t require a load balancer either.
We’ve implemented UAG using Azure AD for authentication. This works well went connecting with the VMware client from a PC, but not so much with a Teradici zero client. We’d prefer not to issue laptops to all our remote workers. Does anyone know of another device option that would function with UAG and Azure AD authentiation?
Zeroes don’t have a browser, which is required for SAML. You can use an on-prem RADIUS proxy instead, and have the UAGs point to it for auth.
https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/auth-radius
Thanks Nick. I’ll look into setting up a RADIUS proxy.
Hey, folks. I would like to share my weird experience installing UAG lately.
With vCenter 6.7 (17137327) Deploy OVF Template feature, it ended up a success of installing UAG Appliance which shows its ip address properly on vcenter. However, by any means, it did not communicate in the network at all. After trying other ways of installing even different builds again such as using esxi vsphere client and powershell, the results were the same. I succeeded in deploying UAGs in my lab (with VCSA 6.5 html5 client then) and another production environment (with VCSA 6.7 html5 client) before FYI.
As a last resort, I used the deprecated vCenter web client to deploy OVF file. The outcome was a success!! I was able to see the ping response and configure it later. It was such weird.
Try web client if you face a failure.
I am having trouble getting VMWare specific OIDs with SNMP.
all detailed here.
https://community.spiceworks.com/topic/2309966-snmp-for-vmware-unified-access-gateway
is anyone monitoring UAG with SNMP ?
Hi,
we added the OIDs in the snmp.conf on the UAG. Restart snmp service and after that we were able to monitor cpu, hdd, ram with the SNMP-Load, SNMP-Memory, SNMP-Storage scripts in icinga2.
Maybe this helps you a bit.
which file of the following did you edit ?
root@UAG [ / ]# find / -name *snmp*.conf
/etc/snmp/snmpd.conf
/opt/vmware/gateway/conf/snmpdv1v2c.conf
/opt/vmware/gateway/conf/snmpdv3.conf
/opt/vmware/gateway/conf/snmpd_default.conf
/var/lib/net-snmp/snmptrapd.conf
/var/lib/net-snmp/snmpd.conf
and what exactly did you add ?
Hello,
Thank you for all the detailed guides. I always refer to them first.
We deployed a VMware horizon 8 environment during its release in the middle of last year. Our external clients connect to the VDI platform using thin clients with built in horizon client -> UAG (v3.10) -> Desktop Pools. This has been working for some time now.
We recently deployed Barracuda LB’s and added additional UAG’s (v20.12) behind it. We have been in test phase for about a month now. External clients connect now using the same thin client -> LB -> UAG and then are presented with their VDI desktop. The issue we have been struggling with is when the LB’s are in line, the external session will disconnect around 20 hours. This coincides with a dated VMware article found here https://kb.vmware.com/s/article/2091458 , but is for legacy clients. We currently have tickets open with both Barracuda and VMware.
With the assistance of Barracuda, we’ve configured the LB’s following Barracuda’s documentation found here: https://campus.barracuda.com/product/loadbalanceradc/doc/24674801/vmware-horizon-view-deployment/. Barracuda has since reviewed our configuration and they are saying the settings look correct. The server monitor is currently set to use ‘TCP Port Check’ health and the persistence type is set to ‘source ip’. Barracuda is currently running packet captures to determine where the session disconnect is occurring.
VMware has suggested changing settings on the CS, however that is working fine without the LB’s in our original deployment method. VMware has also provided documentation on LB monitoring health for timeout settings: https://kb.vmware.com/s/article/56636.
We are trying to better understand the mechanism or process of how the disconnect can occur. My thought is it has something to do with the LB health monitoring configuration, but am unsure at this point.
Thank you in advance for taking the time to read this and providing any thoughts that you may have.
After working with both vendors, Barracuda increased the Health Monitoring time interval setting for ‘Test Delay’ on the service IP from 10 seconds to 40 seconds. Our external thin client and windows client connections have remained connected since this change. After being connected for a period of time, there was some LAG issues in my VDI session. I needed to disconnect my thin client and reconnect it in order for fix the LAG. Still monitoring at this point.
Hi Carl, great Site.
We recently deployed a UAG with Radius and 2 Load balanced Connection Servers behind, and with Radius Auth enabled in UAG we can’t sign in with Domain Prefix anymore coming from external, just with usernames.
So basically:
1. login without domain prefix
2. put in 2FA key
3. login with domain prefix
as soon as we disable Radius Auth in UAG we can login with Domain Prefix\username and we’re logged in directly to shown Apps and Desktops.
Any idea what it might be? Or how to check? Sounds like a Radius issue to me.
Hi Carl,
I build my own lab with 2 connection servers load balanced with netscaler ADC 13 and it works.
To take 1 step forward I deployed 2 UAG 3.10 and load balanced UAG using your guide.
The problem I am facing now is when I configure edge services on UAG, I point to connection server url to load balanced virtual service and I get red in “Horizon connection server” and also I am unable to add gateway in Horizon Console.
Please help
Are you doing DNS name? Or are you doing IP address? If the DNS name has .local on the end, then IP address might work better.
If you download the logs, the esmanager.log might tell you the reason it’s not working.
Hi Carl,
Thanks for your reply, my DNS name has .com and i looked into esmanager.log and found below message.
I am more then Happy to have a screen share session with you, please let me know.
networkcore.HttpsRequestRouter[exceptionCaught: 127][]: [id: 0x717dfd27, L:/10.10.10.41:6443 ! R:/10.10.10.245:1031]: SSLException: not an SSL/TLS record: 474554202f66617669636f6e2e69636f20485454502f312e310d0a486f73743a2031302e31302e31302e34313a3434330d0a436f6e6e656374696f6e3a20436c6f73650d0a0d0a
02/21 09:15:13,574[nioEventLoopGroup-11-1]INFO networkcore.HttpsRequestRouter[channelInactive: 105][]: [id: 0x717dfd27, L:/10.10.10.41:6443 ! R:/10.10.10.245:1031]: Request router channel became inactive
02/21 09:15:31,798[nioEventLoopGroup-3-1]ERROR client.HttpClient[exceptionCaught: 334][]: Exception caught while communication to backend: {}
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: error:141E3152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:471)
Thank you
Hi Carl, great writeup. I have UAG 20.09 clusters running across 2 data centers. Dual NIC deployment, F5 LB. I’m having difficulty with affinity control across data centers. End users connect via single FQDN which load balances across two data centers. In this scenario 50% of connections fail. Looking at logs. I’m seeing primary protocol go to data center A, and secondary protocol gets routed to data center B. As a work around, F5 configuration was changed from Round Robin, to Global Availability. Data Center A is now primary, and B is backup. Auto failover is automatic. I’m lookin for a way to have both data centers active. Will HTTP Host Redirect feature allow both data centers to be active?
In the Horizon Settings, for Blast Gateway, you can enter a datacenter-specific DNS name, assuming the certificate matches both the Single FQDN and the datacenter-specific FQDN.
Your load balancer should follow the persistence of https on the secondary ports.
KEMP calls this port following, not sure how F5 calls this, but their Horizon guide should have this configured. Alternatively, if every UAG has it’s own external IP you could use HTTP Host Redirect.
In both cases on the internal NIC every UAG needs to be able to reach all VDI/RDSH subnets on all sites.
Hilko, thanks for reply. If HTTP host redirect is configured, do i have to modify Horizon Settings and repoint BLAST, PCOIP and Tunnel settings from vdi.mycompany.com to UAG.mycompany.com? Where each UAG will have its own public FQDN.
Yes for the Horizon Blast and Tunnel settings in UAG going to individual FQDN:443 (or 8443 without port sharing), however PCOIP should point to the individual external IP:4172
Hello,
First off, thank you for a fantastic article. I am attempting to set up a dev UAG to CS pairing. I have built a dev CS and stood up a UAG v20.12.
I have gotten the UAG to successfully pair to the CS, and added the UAG to the Horizon Console. I am able to successfully proxy traffic via the Horizon Client, and am successful accessing a desktop over both PCoIP and Blast. HTML access is a different story. When I navigate to the dns name of the UAG and click html access I am prompted with a “waiting” bar, and no place to enter my credentials. I have disabled checkOrigin and added the dns name of the UAG as a portalHost key and balancedHost key in my locked properties file. I have also added a lengthier proxy pattern: (/broker/xml(.*)|/xmlapi(.*)|/broker/resources/(.*)|/ice/(.*)|/r/(.*)|/portal(.*)|/appblast(.*)|/view-client/(.*)|/). The issue appears to be posting the sessionID to the CS, as recording my network traffic in chrome shows a hung post request back to the CS. In the esmanager log, I am simply seeing a closed connection from the UAG to the CS.
If anyone has experienced something similar, I would really appreciate a response! Thanks in advance.
I have recently deployed 20.12 version of UAG & have issues getting the right certificate installed.
The UAG appliance is currently accessible via https://uagipaddress:9443/admin & I have got a certificate that has the CN & SAN as uagipaddress:9443/admin but i keep getting NET::ERR_CERT_COMMON_NAME_INVALID Error. Is there a way to resolve this? I’m unclear why it keeps saying invalid CN.
When installing certificate, are you choosing “admin interface”?
In Chrome, press F12 on keyboard and go to Security tab to see the actual certificate problem.
I see the error:
This site is missing a valid, trusted certificate (net::ERR_CERT_COMMON_NAME_INVALID).
I am using the certificate for both admin & internet interface. Any suggestions?
For some reason I can’t deploy successfully the UAG 20.12.
I enter a static IP for nic1, after it powers on it selects a DHCP address, it is pingable, but not reachable on 443 / 9443
I tried several times to deploy it with DHCP, but still no access to REST administration on 443 / 9443
Hi. Step 11 is where the script hangs for me.
‘Enter login information for target vi://[ip address]
‘Username: admin%40vsphere.local’
that’s where it hangs. I notice that a) it uses the %40 instead of @ and b) it never prompts for the password.
i dont think it is an issue with the vsphere.LOCAL, as that’s just the username, our domain is not a .local
Sorry, wasn’t clear.
When I run the ps1 script to install the UAG it hangs on Step 11 with the above information.
Can someone give me some assistance on what i’m doing wrong?
Thank you.
Hi Carl,
I have such a problem: when deploying UAG 20.12 from ovf on the vcenter 6.5 (html5 ver), when 2NIC is selected, the settings fields for the second interface are not visible. Maybe you can help me with this? There is no such problem for the Flash version, but Flash is prohibited for use in the organization.
I think it was fixed in 6.7 Update 3.
Another option is to use PowerShell and .ini file to deploy the appliance.
Hi Carl,
when configuring my UAG Horizon settings, the Horizon Destination server shows red.
Connection Server URL: I have entered the connection server load balancer FQDN
Blast External URL: I have entered the GSLB FQDN
Blast is green but Horizon Destination Server still red
Is the certificate trusted? Did you enter the correct thumbprint?
On the main UAG admin page, at the bottom is a link to export the logs. Look in esmanager.log for errors.
When I use the LB IP address, all goes green, but the LB FQDN makes it go red again
Does the FQDN end in .local?
Is DNS configured on the appliance?
I am checking the DNS entries on the UAG, in the meantime, when configuring the Gateways on the Connection Server, should I register the UAG Loadbalancer or the UAGs themselves
See https://www.carlstalhood.com/vmware-unified-access-gateway/#adduagtohorizon
Hello Carl,
I did the configuration of UAG, and once I tried to connect by a client I received an error message ” Could not establish a tunnel connection ” Knowing that I enabled tunnel from UAG horizon settings, and I unchecked uncheck or disable all three Tunnels/Gateways, could you please tell me your conclusion or how I can solve this issue?
your speedy response will be appreciated, thanks in advance.
Do you see the list of icons? If not, then I’m guessing the Tunnel External URL configured on UAG is incorrect.
Thanks for the excellent work on your blog here. I find your posts extremely helpful!
I have Horizon 7.10.2 and am working on replacing my Security Server with a UAG. I have the UAG up and running but am using a single firewall setup with two NICS on the UAG both on the same subnet in the DMZ with proper rules setup for the different traffic.
Is this a supported/recommended configuration?
I have everything working except clients freeze for 20-40 seconds every20 minutes if on PCOIP and disconnect if using RDP or Blast. VMware support points to a firewall issue and am trying to track that down. In my work so far, it appears the issue may be with the backend “internal” NIC.
I’m a bit confused by the download options from VMWare. I’m currently on 7.12 with 1 security server. Plan is to migrate to UAG, decommission security server, then upgrade Horizon to 2006. However, if I select Horizon 2006 or 7.12 in the VMWare download section, it gives me UAG 3.10, but if I select 7.13, it gives me the option of UAG 20.09. Is there a reason for this or just a glitch on their download portal?
Horizon 7.13 is newer that Horizon 8 2006 and thus Horizon 7.13 has the newer UAG. Check the VMware Interoperability Matrix to see which UAG versions work with your version of Horizon.
Wow, thanks for the quick response!! That’s a strange way naming convention…
They changed naming standard to YY.MM so 20.09 = September 2020
Is there any write up available on migrating from Security Server to UAG? I opened a ticket with Horizon support but they are taking their sweet time in responding?
It’s easiest if you keep the same public IP and public DNS name for UAG and Security Server.
Deploy your UAG appliances. Configure them in Horizon Settings with the same public IPs and FQDNs as your Security Servers. Load balance them on a new VIP. Ensure firewall allows the UAGs to talk to your Connection Servers and Horizon Agent machines.
You can test Blast and RDP by modifying your local HOSTS file to resolve the FQDNs to the UAGs. PCoIP can’t be tested like this because it is IP address instead of FQDN.
On cutover night, in your external firewall, change the NAT for the public IP to translate to the UAG load balancing VIP instead of the Security Server load balancing VIP.
If everything works, then remove the Security Servers from the pod (Horizon Console).
Hallo Carl,
I did exactly as you mentioned above.
Roget: It is much simplified than I have imagined. But needs detailed planning.
Here is what I did. May not be the best way. You must have maintenance window
1. We had 4 x security server. we shutdown 2 of them.
2. We use same ip of securityserver01 and securityserver02
3. deployed uag. Take care out routes.
4. Most important i noticed, DNS between uag and view connection must be opened
5. 443 between uag and view connection server was not opened. Other ports you can leave as is and you can close them after migration.
6. As plan B do not remove or uninstall securityserver01 and securtiyserver02.
7. Shutdown securityserver03 and securityserver04.
8. do testing. all is good. when you simply cleanup security servers.
Hi Preetam,
Can you elaborate on your step 3 “Take care out routes” and step 4? I spun up an UAG and able to connect to it’s admin portal and SSH, but from UAG, I’m unable to ping back into my internal network.
Security Server: 10.1.100.100
UAG 10.1.100.101 1 NIC and set to all DMZ network
Subnet: 255.255.0.0
Default GW: 10.1.100.1
DNS: 10.1.1.10 8.8.8.8
Connection Server: 10.1.1.20
DNS Server: 10.1.1.10
Sorry I missed one thing. We deployed Single NIC architecture.
In single NIC, route should be configured to reach view connection server and Desktops.
Your DNS should be able to resolve connection server and desktops.
If this is unclear you can reach me via twitter/linkedin @preetamzare
Hi Preetam,
Thanks for the suggestion, however, I know that ICMP is allowed from the DMZ as I’m able to ping from the Security server to Connection. I’m also able to access https://ConnectionServer:443 from the Security server which indicates both ICMP and DNS traffics are passing through from DMZ to Connection.
I keep coming back to the step 8 on “To deploy UAG using vSphere”, in Carl’s example, he selected DMZ for Backend, Management and Internet. I’m wondering if I need to change the Backend to the Connection server vLAN. Thoughts?
Also, feel free to email me at vmadmin@evergreeneye.com if it’s easier to communicate.
If you want we can have a quick look on Zoom, send me an email on first letter of my first name and full lastname at your favorite virtual software provider.
Hi Preetam, the issue I’m having is the I can’t ping from UAG (DMZ vLan) back to my Connection server and desktop VLAN. I’m able to ping from Connection server and desktop to UAG. My Security server is on the same DMZ vLan, and I’m able to ping from that which indicates that its not being block by my network. I also configured the UAG with 1 NIC.
Two things you have fixed from DMZ to your connection server and Desktop.
1. allow ICMP traffic
2. allow DNS traffic
Unless it is done, you will see Red on Horizon connection server.
from your UAG execute this command
curl -v -k https://hostname-or-ip-addressofyourconnectionserver:443/
Thank you!!
Hi all, thought I give a quick update on this in case others run into the same problem. Finally got someone knowledgeable from VM support. Turns out I needed to update the Proxy Pattern to
(/broker/xml(.*)|/xmlapi(.*)|/broker/resources/(.*)|/ice/(.*)|/r/(.*)|/portal(.*)|/appblast(.*)|/view-client/(.*)|/)
Once updated, everything worked!! Thanks all
Hi Carl,
Following your awesome article, I was able to spin up an UAG20.09 and everything seems to be good, I’m able to access the admin portal and SSH from any internal device. However, I’m getting red on Horizon Destination Server when I configured the Edge Service Settings. After some testing, it appears that UAG is not able to pass traffic to my internal network and unable to communicate with the Connection server. I mirrored the network settings based on my current Security server, so there shouldn’t be anything that would be blocking UAG.
Selected DMZ for all 3 networks (internet, management, backend), 1 NIC.
DMZ: 10.10.100.0/24 (Security server and UAG)
Internal: 10.10.1.0/24 (Connection and DNS servers)
From UAG, unable to ping to 10.10.1.0/24 but able to ping 8.8.8.8. No issues with any internal device connecting to UAG.
Any suggestion is greatly appreciated.
Hallo Carl,
I’m new to UAG.
I’m coming from the “security server” background.
I have used your blog extensively to configure Netscaler to load balance security servers.
We have following setup.
we have Netscaler
It is load balancing 4 x security servers. In this model, we do not need to load balance connection servers because security server and connection servers have one to one relationship.
Now I’m wondering how do I move from this architecture to UAG
I definitely would need two UAG, since we have netscaler I would prefer to use netscaler to load balance instead of UAG inbuilt functionality.
But what about from UAG to connection servers?
Referring various online resources I understand that with UAG, we need to load balance connection servers also?
Is this right?
You can do a 1:1 connection between CS and UAG and this would be what I’d normally recommend. For management purposes we normally recommend a pod local VIP, and for internal users a cross pod VIP, but UAGs can go straight to CS.
Thanks a lot for your response. I took time to digest what you are recommended. After reading vmware document I would like to know if this is what you proposing
uag1.vmware.com —> viewconnection01
uag2.vmware.com –> viewconnection02
uag.vmware.com –loadbalancing_legs–> uag1.vmware.com and uag2.vmware.com
And is this supported?
Yes, that’s what I meant, plus separate VIPs to CS for management and internal usage (which UAG does not leverage).
Of course we support it, else I wouldn’t be saying it.
Thank you again. It is so nice of you taking time to respond on it. We have very interesting problem for internal VIP. We can only do LB coming from external connection. Even if we have to LB internal nodes, traffic goes via FW -> LB. This is completely comical. I know. But your respond gave very good insight
The loadbalancer in front of the UAG’s monitors the health of the UAG’s, but what happens if the connectionserver behind one of the UAG’ is unavailable ? In that situation both UAG’s are still healty from view point of the loadbalancer.
An UAG is a reverse proxy, meaning the favicon comes from the CS and not from the UAG.
One question further on this. We have configured 2 x UAG and 2 x view connection server as mentioned by you.
So simply stated, UAG is load balanced using Netscaler. In this case do you need session persistency to be configured on netscaler. I think we need it right?
Yes, you need to always hit the same UAG. When using N+VIP for public IPs you could leverage the forward instead of persistence, but when loadbalancing the protocol too you can’t.
Hi Carl,
First of all thanks for all tuto you made.
We have a strange issue when trying to configure UAG to connect to Horizon Connection server.
CS appears down with red circle.
We installed internal CA signed certificate on connection server.
DNS resolution for CS from UAG is ok, ports are open.
I’m pretty sure it’s related to the certificate but no matter what typology I use for the certificate thumbprint (sha256=XX XX, sha256=XX:XX, sha256=XXXX…), the connection between UAG and CS still appears down.
Do you have an idea of I can I troubleshoot this please ?
Thanks in advance,
Best Regards
Certificate thumbprints are usually sha1.
Thanks for your reply, do you mean that we have to recreate certificate with sha1 encryption algorythm instead of sha256 ?
or even if it was encrypted with sha256, I have to put sha1= for certificate thumbprint ?
Thanks a lot and sorry if it seems basic.
Hi Carl and thanks for your reply.
Ok I thought thumbprints were generated using same algorythm than the certificate itself.
So many time loss just for that.
Thanks a lot, I’ll give it a try
Hello Carl. Excellent guide…always stop here first. I just deployed a new environment with 2 UAGs behind a load balancer. My Horizon clients are reaching the brokers as I’m seeing entries in the event log, but on the client side, they get a timeout and never connect. I know there are a million variables, but any thoughts on how to troubleshoot or a setting I might be missing?
Ports not open on external firewall? Persistence not setup correctly?
Hi Carl,
We are working in a new implementation of VMWare Horizon with UAG as Gateway Access from Internet.
We want to authenticate the session with a certificate and inspect a specific field of the own certificate and compare with a list of objects that we got in a specific file or an AD specific attribute (Not the UPN).
Actually we have configured the access with the certificate but we need implement the feature of inspect the field.
Futhermore we dont know why the VMWare Horizon Client its not working against the UAG access with certificate. It’s that the expected behaviour or its neccesary activate any feature on the UAG configuration?
Regards
On the UAG > Horizon Settings > More, what Auth Method did you choose.
I don’t think UAG is able to check a specific cert field.
Where is the cert on the client machine? If Computer Store, then users need access to the private key.
Dear Carl,
First of all thank you so much for all your articles and documents that has been our reference point for so many years.
I am stuck with a situation where we are trying to implement a solution where we need to access VDI’s sitting in an isolated environment.
Our Design in as below;
Laptop –> VPN (RSA Secure ID)–> UAG(.509 Device Auth from Laptop) –> Horizon Server (Smart card Only for User Auth) –> VDI
GOAL : Authenticate User & Authenticate Device to allow user to reach VDI and only through virtual DMZ that is VPN Subnet.
Special Secure Laptop –> Connects to a VPN Solution (This VPN does an authentication based on RSA- Radius, but does not authenticate the device) –> VPN subnet is working as a DMZ –> From here you can connect to UAG (UAG is doing .509 Device authentication – works perfectly Till here –> Once authenticated to UAG you need to authenticate to Connection server and this is where we fail , Our Connection server is setup to accept only Smart card authentication . Problem in our case is UAG is not passing or redirecting PKI token to connection server at this point and horizon client throws an error “Smart card authentication is required”.
But if we change the Smart card authentication on Connection Server it immediately shows a dialog box for username and password which for this isolated environment is being scrambled but we did a quick test by creating a test account and i was presented with VDI pool. now at this point VDI’s also need 2-factor authentication and they can now see the PKI token, so redirection of PKI works once you are inside VDI.. so all goes well from here if we don’t use Smart card on Connection server for User Authentication.
So either UAG is not redirecting and presenting token to connection server during authentication OR Connection Server is not fetching Smart card from Laptop via Horizon Client OR May be Horizon Client is not presenting Token to Connection Server.
I have reached out to VMware logged a ticket with them, shared tons of logs from UAG, Horizon Server/Client but of no use. They haven’t reached for any solution and neither they are accepting the fact that UAG is not capable of working when Horizon Connection server is set to Smart card authentication only for users.
I was hoping to check with you, if you have come across a similar situation or if I can request you try this in your LAB and see if it works for you or Tell us what wrong are we doing here.
NOTE : when i tried this, we had Horizon Server and Agent 7.12 and UAG 3.12, I have upgraded Horizon now to 8 and will soon upgrade UAG to 20.09. there is only 1 UAG and 1 connection server. This is a very special setup for a special environment and we desperately looking into getting it working.
Regards,
Sandeep Raut
Since UAG is terminating the SSL connection, you can’t do normal certificate authentication to the Connection Server. Instead, you do SAML between UAG and Connection Server. See https://www.reddit.com/r/vmware/comments/ev9tpm/vmware_uag_and_smart_cards/
Hi,
We want to transfer UAG logs to Archsight via syslog. Do you suggest configuring uag admin console or via server for syslog setting?
Regards
Why not both?
Dear Carl,
Thanks for you Articles. it always a knowledgeable, just i have once question, i have deployed UAG for our external users but the VDI is working from external by Horizon client but from url is not working… we have open all port from any to any but still the same issue, we didn’t have any load balancer. please help me
Carl do you still have a page for True SSO enrollment Server?
I have not written one yet, but I think there are some other blogs with the info.
is it true that you need vIDM to enable true sso ?
Not any more. Recent versions of UAG and Horizon now support SAML natively. To eliminate the second logon you could deploy True SSO.
ok, cool, thanks for answering, will have a look to the official documentation.
Here’s one guide for Okta – https://techzone.vmware.com/enabling-saml-20-authentication-horizon-unified-access-gateway-and-okta-vmware-horizon-operational
Can I do external NAT to UAG High Availability Virtual IP? or I need to have another LB VIP?
Yes. But you also need public IPs for each of the appliances.
Hi Carl,
I have a DNS question regarding the UAG. Our UAG appliance is in the DMZ, and our DNS servers (and view connection server, etc) sit inside the firewall. The DMZ has a route to the internal DNS servers, and the UAG is able to successfully connect to the view server, etc. So far, so good.
When I select the VMware Horizon HTML Access, I am prompted for my credentials, and am able to authenticate and sign in. However, when I click on the normal desktop pool, I am directed a page that references the URL of the internal connection server, and am told that the site can’t be reached. The fact that it can’t be reached makes complete sense to me, as the connection server is inside the firewall and is not public facing. Naturally, it has no public IP address either. Even if I apply a DNS entry to the public facing DNS servers, that IP address will not be reachable as it is an internal address only.
Do I have something completely misconfigured here, or am I missing something obvious? Thanks for your thoughts on this!
In Horizon Console, go to Settings > Servers > Connection Servers > Edit. Make sure the HTML Blast Gateway is disabled.
Thanks Carl!
I checked the settings (v7.11) and I have the “Do not use the Blast Secure Gateway” option selected. Any other ideas on this?
UAG > Horizon Settings has the external URL (not internal URL) in Blast Gateway?
Hi Carl,
I have a strange situation that I’d like to get your input on. I have a V7.11 connection server, and a UAG running version 3.8. The connection server sees the gateway server, and the gateway server sees the connection server. All appears to be good there. I recently applied a new SSL certificate to the connection server, and that certificate shows up correctly when I browse to the connection server. I copied the thumbprint to the UAG server. However, when I browse to the UAG server URL, I’m told that the session is not secure. Further, when I look at the certificate details, they appear to belong to the self-signed certificate on the connection server, and not the new SSL certificate.
Any idea why this might be, and what actions are needed to get the UAG server to correctly use the signed certificate on the connection server?
Thanks!
If you browse to UAG, then you’re getting a UAG certificate, not the Connection Server certificate. In UAG, go to TLS Server Certificate Settings and upload a certificate. Easiest is PFX with full chain.
Hi Carl,
We use cascade mode with 2 x frontend and 2 x backend UAG (per-app-tunnel for iOS & Android devices) on port 9443 but reading through the HA section, I can see that it talks about port 443. I don’t see any setup documentation with regards to our exact scenario?
The VMware videos don’t really go into it either.
Can you help?
Hello Carl, I am testing the UAG and cannot launch a RDP session on an internal PC. I have not found a definitive document on what is needed in terms of ports. I am using the web client ->UAG on tcp:443. From that I have tcp:443 going to the connection server(s). The message I get is ‘Unable to set up the desktop session for the display protocol.” Any quick thoughts? What am I missing? Thanks.
For RDP, I think you need to open TCP 3389 from UAG to the desktops. Blast might also work.
So I actually get this from inside as well. I may not have mentioned but the desktop is physical. Thanks.
Hello Carl,
First of all, thank you for the tutorial!
We’ve upgraded our UAG’s from v3.3 to v3.10 and everything went fine (just as you decribed). However, now users start to get the following message when trying to connect:
VMware Horizon Client cannot verify your connection. The server provided a self-signed certificate instead of a verifiable certificate. Because the server has provied a verifiable certificate in the past, there is a strong likelihood that your connection is not secure.
Do you have an idea how this can be fixed? Than you very much!
If you exported/imported the config, then be aware that the certificate is not included so you’ll have to upload it again.
Thanks Carl, i exported/imported the config, but the old UAG’s didn’t have the certificate either. They are behind a load balancer.
Uploading the certificate did the trick. Thanks!
Hi Carl, first of all let me thank you for the tutorial, it has helped me a lot, I have a question, I am doing a PoC and we only use one NIC for the UAG. To enter the horizon environment from the internet, I am using a NAT from a public IP to the internal IP of the UAG, like this: https: //x.x.x.x: 444 = https: //x.x.x.x: 443. The user can log in correctly, but when requesting the desktop, it is looking for the internal IP of the UAG using BLAST, do you know what I need to configure in the UAG to be able to show the desktop?
In UAG > Horizon Settings, did you set the URL to :8443, which is the default for blast? Or are you doing port sharing on :444?
Thanks Carl, on UAG >Horizon Settings I set the URL like this:
Blast External URL: https://10.1.10.248:8443 (IP 10.1.10.248 is the internal IP of the UAG) on the firewall I am configuring a NAT https: //187.188.x.x: 444 to https: //10.1.10.248:443
I am working like this because of lack o resources for the PoC
Do I need to change the Blas External URL to https://187.188.x.x:8443??
Regards,
:8443 is the default. You can try :444 to match your external port.
Hi Carl,
thanks for your great arcticle!
In case I hosted the Workspace ONE UEM environment for the customer and installed the UAG on customers site, which steps are imported to ensure no SSL errors between UAG and customers environment and UAG to WS1 environment?
I did the following:
– SSL PFx Cert from the hosted environment imported into the UAG webconsole on the Internet interface (Admin Interface will be used with the customers certificate
– Root, Intermediate Certs from the customers environment and the hosted WS1 environment into the trusted certificates from each Edge Service
Anything else?
Thanks.
Magnus
I see you do work with the Netscaler and it’s similar to UAG and I know the recommended Netscaler be on the Edge you can give it a public IP and I think that was a recommended config. Anyone know if UAG is secure enough to do the same? With built in load balancing you could give the front end NIC 2 public addresses, it’s own, and lb and then a backend NIC in a DMZ with static routes to the networks it needs access to. I can’t find anything on if that is a recommended setup or prefer behind a firewall because it isn’t secure enough on its own.
I prefer to put a real firewall in front of these devices.
Carl you should mention or add that with UAG 3.7 HA will fail because the account HA is trying to use has an expired password. It failed while I was testing HA setup (GUI would show the error FAULT), I found the error that was causing the issue in the /var/log/messages log. I reset the password for the “gateway” user account, . Once I reset the password using the standard “passwd” linux command utility, reenabled HA via the UAG GUI, HA came up as expected.
Hi,
Great guide, regarding 4c for adding a new static route, do you happen to know the command for adding this outside the GUI?
Thanks
To automate a UAG, try the PowerShell script. The INI file should have an option for static routes.
Hi, the UAG is already installed but some of our static routes magically disappeared overnight. I found this command in a tech note so wondering if it would work so I can add them quickly to get the service back up and running: route add -net 10.1.101.0 netmask 255.255.255.0 gw 10.1.100.1 dev eth1
FYI: This may work for what you are attempting but it is a temp route and will “disappear” the next time you reboot the appliance.
Instead of adding routes manually whenever a new subnet pops up, just set all RFC1918 networks to NIC1:
routes1=10.0.0.0/8 10.6.4.1,172.16.0.0/12 10.6.4.1,192.168.0.0/16 10.6.4.1
Just replace 10.6.4.1 with your gateway. Any other IP (Internet) will go to the default gateway on NIC0, and as the range on NIC0 will be smaller than those RFC1918 ranges even subnet local IPs will go there.
Don’t use routes for security as it’s just obfuscation, use a firewall for security. Talking about obfuscation, you get a bit of that with this as your local subnets are not visible with this method.
Hi Carl, Thank you for your awesome site.
I have problem with UAG 3.9.1 and certificate with alternate names (SAN). When connecting with Horizon Client everything is OK. But when I use web browser to access my desktops, it can only be done when connecting to commonName of certificate. Accessing web by any of SAN names result in error “Failed to connect to the Conection server” when clicking HTML Access. Log didn’t help me.
Is checkOrigin disabled on your Connection Servers?
That’s it. I actually didn’t turn off check origin. But I specified portalHost as mentioned in vmware documentation and now I forgot to add subject alternative names of new certificate. Thank you for pointing this out.
Hi, I am wondering about DNS in a DMZ configuration. We have active directory integrated DNS, and would have to open DNS service from the DMZ to one or more of our Domain Controllers to use DNS on the UAG back to the LAN. Is this the typical practice? If so, it seems that would be included in the list of ports needed for the UAG setup to work. Just wondering how others are doing this?
Yes, you either use internal DNS or resolve.conf and put the lookups in manually.
This is the best guide so far for UAG deployment, even VMWare KB also is not detailed as this. Thank you soo much!
Hi, I was wondering if you have any recommendation on if it’s ok to run UAG in a 2NIC setup with 1 NIC in the WAN and the other in the DMZ with static routes to connection server and agents. Currently I just use a single NIC deployment in the DMZ with a NAT from public IP to DMZ IP and a VIP to load balance the initial connection. Wondering if the appliance is hardened enough to have it’s external interface on the WAN. My main reason for wanting to investigate this route is when I have any hiccup with my front end firewall or upgrade it etc etc it takes out UAG access, so if I only took out internet access out that would be better with UAG continuing to function aside when it gets updated,
The recommendation is to have at least two NICs and to put those in an external and internal DMZ. External DMZ is inbound only, Internal DMZ allow access to DNS, CS and agent subnet.
Hi, I discover that if use dns search in ova then not connect to admin https, refuse to connect at all, in 3.9, 3.6, 3.5 and others. My domain its .local
FYI
Known issue: see https://arnomeijroos.com/2020/02/18/how-to-fix-dns-issues-on-the-vmware-uag/
That is not an issue. You should never use .local as a domain name, nearly everyone has been warning about that for over two decades. Even Microsoft has for more than a decade.