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
Hi,
When the web ui can’t be accessed and want to double check my UAG network settings:
I noticed the new UAG versions now has a new directory to edit the network settings: /opt/vmware/gateway/scripts/configureNetwork.sh – Is there a new how to/guidance on the cmds (i.e enter eth0 then followed by network interface ask what mode I wanted). you can provide with the new settings on editing the network settings. Omnissa made it more complicated. TY!
Omnissa Support usually prefers a re-deploy rather than manually changing the appliance network config. If it’s on the network but the admin GUI doesn’t work, then that’s usually an admin password that is not sufficiently complex.
Hi Carl,
We have just rolled out Horizon 2312 (connection servers behind a load balancer with UAGs in front of the connection servers). When we connect to a UAG or the URL for external access, such as https://uag-1.domain.com the response for the URL includes a parameter like this:
https://uag-1.domain.com/?includeNativeClientLaunch=true
This makes the HTML elements not display properly. If you update the URL in the browser to indicate the parameter to be …/?includeNativeClientLaunch=false, the web page displays the HTML correctly as far as font size and spacing.
Our users need to access the environment via HTML. Also, we want them to have the option to download the Horizon client when they land of the webpage, but not have the option to launch the native client.
When connecting to just the connection server, this parameter is not automatically appended to the URL, so the page displays properly with the options of ‘Install VMware Horizon Client’ with a download icon on the left side and ‘VMware Horizon HTML Access’ with another icon on the right side of the default center box.
Any idea on what is causing this or how to change it so the native client option is not specified or a way to set it to false?
Is there a good way to block the view servers from end users directly connecting to that server? We are using a UAG internally but technically a user could open a browse and connect directly to a UAG server
Firewall. UAG can be configured with a management NIC and one or two data NICs. Restrict access to the management NIC.
Hello Carl,
do you know why uag 24.06 is getting “Error in serving the request.” ?
Tried upgrading from 23.03 and imported the json, had to change the thumbprint to use sha256, the edge service is showing green , but the published url just gives that error
Hi Adi,
i had the same issue. Looks like thre is a change.
I could only connect to the configured URL which is configured in “Blast External URL”
In my case this is an alis for the HA IP address.
Maybe bug or feature 😉
Hi Adi,
we had same issue with Secure Email Gateway role on UAG v2406.
It seems like a new bug in this version.
We eventually decided to go with v2312 where same configuration does not result with that weird “Error in serving the request.” message.
Hi Carl,
right now I am experiencing an isse that even the Omnissa Support has problems nailing down.
Whenever I try to connect via the UAG i always get a VDPCONNECT_REJECTED. A connection directly to the connection server works without issues and I get a machine immidiately. All ports are wide open between UAG, CS and VDI VLANS because i wanted to rule out network problems.
This is what I’ve seen as well. Directly to the connection servers worked without issues also. Let me know if you ever figure it out with them.
Hi Carl,
Under the “UAG Admin Interface” section at step 11 maybe please add the full proxy pattern settings string which should be used:
(/|/view-client(.*)|/portal(.*)|/appblast(.*)|/downloads(.*))
And maybe also add a reference to the Horizon Connection Server page where you describe how that downloads folder should be created and filled.
For guys who don’t know about the correct settings this would be a tremendous help to do it right I think.
Sorry for the delay. I made the requested changes. Thanks for pointing this out.
We recently upgraded our UAG from 23.03 to 23.12. My organization uses smart card authentication, just the same as Rickard.
After the upgrade, we consistently get the following error from our Horizon client:
-> This Horizon server expects to get your logon credentials from another application or server, not directly through the client login screen. If you usually access Horizon from another application, please launch that application.
Our set up is:
Horizon Client Version 5.5.4 -> UAG 23.12 -> CS 7.13 -> Horizon Agent (I’m not sure about the Agent version)
I rummaged through the esmanager.log file on the UAG and found the following:
[d7fd-***-0c3f-***-3747-***-4949]: Received success response from CAS for user: 1234567890@mil
06/27 09:11:03,199-0400[jersey-client-async-executor-9]INFO request.BaseAuthentication[logMessage: 274][10.10.10.10][][Horizon][d7fd-***-0c3f-***-3747-***-4949]: Authentication successful for user 1234567890@mil. Auth type: CERTIFICATE-AUTH
06/27 09:11:03,199-0400[nioEventLoopGroup-7-5]INFO proxy.HttpsBackendConnector[write: 171][10.10.10.10][][Horizon][d7fd-***-0c3f-***-3747-***-4949]: Inb Ch : [id: 0x021be67a, L:/10.10.10.11:6443 – R:/10.10.10.10:58611] Outb Ch : [id: 0xd64b50f0]. Connecting proxy with retry to backend myhostname.mil:443
06/27 09:11:03,211-0400[nioEventLoopGroup-7-5]INFO proxy.HttpsBackendConnector[operationComplete: 185][10.10.10.10][][Horizon][d7fd-***-0c3f-***-3747-***-4949]: Inb Ch : [id: 0x021be67a, L:/10.10.10.11:6443 – R:/10.10.10.10:58611] Outb Ch : [id: 0xd64b50f0, L:/55.32.254.164:32954 – R:ngncl6-350-01.ng.ds.army.mil/10.10.10.11:443]. Connected to backend channel
06/27 09:11:03,317-0400[nioEventLoopGroup-7-5]WARN util.ConfigKeyParameterHelper[generateUagAndBrokerSharedSecretKey: 455][10.10.10.10][][Horizon][d7fd-***-0c3f-***-3747-***-4949]: UAGW00255: No key materials received from connection server.
06/27 09:11:03,416-0400[nioEventLoopGroup-7-5]INFO response.SubmitAuthenticationResponseProcessor[processDocument: 133][10.10.10.10][][Horizon][d7fd-***-0c3f-***-7af8-***-47a5]: Authentication attempt response – error, user-sid:
06/27 09:11:03,416-0400[nioEventLoopGroup-7-5]WARN processor.XmlApiMessageProcessorUtil[persistFailedLoginAttempt: 546][10.10.10.10][][Horizon][d7fd-***-0c3f-***-7af8-***-47a5]: UAGW00108: Authentication attempt – FAILED, error code – AUTHENTICATION_FAILED, error message – Authentication failure, user message – This Horizon server expects to get your logon credentials from another application or server, not directly through the client login screen. If you usually access Horizon from another application, please launch that application.
My thinking is that the critical line is: UAGW00255: No key materials received from connection server
Do you have any notions about what could generate this log, and on how I can fix it?
ran into the same issue last night .. getting same error when upgraded to 23.12
Anyone figure out any fixes for this?
Hi Carl, we migrating our existing and working VDI Farm and we set up UAG in external DMZ und Connection Servers for internal and external logins in internal DMZ. As you described in tunnel mode the options for tunneling in Connection server settings have to be unchecked and this configuration has to made in UAG. We want by external logins over UAG->Connection-Server(placed in internal DMZ) that the whole connection stream will be established over UAG and Connection-Server and not bypassing 4172,32111,22433 and 9427 the Connection-Server. In my understanding an attacker who has access to UAG, he has also network access to the VDI Agent IPs. How can i solve this problem? I saw in firewall logs that PCOIP from external logins goes through UAG and Connection-Server(and not bypassing PCOIP which is good) but 9427 and 32111 bypasses the Connection- Server. In the Case of Blast the UAG wants direct Communication to the VDI Agent IPs over 22443. i dont want to open the ports from external DMZ direct to internal VDI Agent IPs.
Thanks for your help
Christian
Try Double DMZ – https://docs.omnissa.com/bundle/UnifiedAccessGatewayDoubleDMZDeploymentforHorizonV2309/page/UnifiedAccessGatewayAppliancesDeployedinaDoubleDMZ.html
Hey Carl,
We are planning to use a UAG internally to force MFA with Microsoft Authenticator using SSO – My question is does the UAG server need to be accessible with a public IP address to communicate to Microsoft or can it just be an internal server non public facing
Only the client machine needs connectivity.
Hi Carl,
We are looking for the RADWARE parameter to allow persistence across multiple port numbers so when the load balancer selects one UAG for the primary protocol (443), the same UAG is used for the secondary protocol (8443 or 4172).
Do you know where to find it?
Thank you.
You mentioned NetScaler and F5 but we need to find the option for RADWARE: “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.”
Deploying UAG1 as a reverse proxy in dual DMZ. When UAG2 is Horizon EDGE, it works normally internally. How to set up the network or configure UAG1 to achieve Internet access,
Hi Carl,
New to horizon, I just have set up Horizon 2312 Connection server.
All looking good, suddenly external ip getting not reachable.
Connection server is working, all the services are running, not network related issue.
I had to restart connection service to get it back alive.
Strange that connected users didn’t got affect until I restarted the service.
*attaching a screenshot of dashboard system health showing connection server’s errors
-Errors
No problem detected.
Detected Unrecognized Requests
https://ibb.co/kMRLDxN
Did you had something similar before?
Thank you
Any load balancer?
Check c:\programdata\vmware\vdm\logs
No load balancer
But what should I look for…?
After all connection is not lost..no new connections can be established though
Thank you
How to Add another admin Privilege Administrator account ? as on our enviroment they requested to have multiple admin accounts
is it possible to add ?
I have a situation where my ESXi host are in different vLAN subnet. AVI NLD connect to the vCenter with no issues with management network, however, failed to access ESXi host. How can i resolve this issue?
Trying to get UAG HA to work. Doesn’t seem to pass the connection to the backup UAG. The backup HA never receives any traffic.
Does anyone have this working and know the correct settings for what goes in the UAG and the Connection servers? I may have something misconfigured
UAG now has OCSP stapling enabled by default which requires firewall access over port 80 or 443 to the OCSP domain of your Certificate Provider, eg. http://ocsp.digicert.com
There’s a number of comments here about the SSL handshake issues, which I also experienced until the FW rule was put in place.
I have requested VMWare to update their DMZ UAG Firewall Requirements document.
I’ve just taken over our Horizon environment and so glad I found your blog.
When looking at our UAG’s there is a Red Dot next to UDP Tunnel Server.
I cannot figure out where there is an issue. We are going through Netscaler and there are service groups setup for UDP 443.
What are the key features of VMware Unified Access Gateway 2312?
See https://docs.vmware.com/en/Unified-Access-Gateway/2312/rn/unified-access-gateway-2312-release-notes/index.html
How to add another admin privilege account on the UAG 23.03 ?
I have upgraded my UAG 2306 to 2312 and imported the config. Initially it doesn’t show the imported successfully message instead it shows the imported partially and xxx persists settings. So i changed the sha1 to sha256 for my connection server and reimport again, now i can see the horizon in edge service but still received the same error after import. Then now my HA VIP cant be accessed through fqdn, access via IP is fine. Dns and host file all fine.
I guess I’ve found the issue for inaccessibility of FQDN VIP. I’ve noticed from the file that the UAG added all hostname and IP address related to itself to Allowed Host Header automatically. But I don’t see the FQDN of my HA VIP is being added, so I manually added that on both UAG and now I can access it.
Hi Carl,
First of all, I would like to thank you so much for all your good articles and documents that you have provided. I have been working with Horizon on and off for a couple of years but every time I do your documentation help us out.
I’m stuck with an issue regarding smart card integration. I have read all the comments on this article, but I cannot still get it to work with newer versions then 7.13 of Horizon.
I have an old environment where it works flawless. Laptop > UAG > CS > VDI. The goal is to authenticate the user in the UAG step. Currently I have two Horizon instances in the same domain for testing purposes with different versions. I have setup SAML between UAG and CS successfully in my opinion. Passthrough works prefect in both setups, but when switching to X.509 Certificate it won’t work in the newer version.
Setup with old versions:
Horizon Client 2312 > UAG 7.13 > CS 7.13 > Horizon Agent 8.12.0
Setup with new versions:
Horizon Client 2312 > UAG 23.12 > CS 8.12.0 > Horizon Agent 8.12.0
I have tried multiple versions between 7.13 and 8.12.0 but I still get the same error message in the horizon client:
This Horizon server expects to get your logon credentials from another application or server, not directly through the client login screen. If you usually access Horizon from another application, please launch that application.
Looking into the logs I can see the successfully authentication with smart card in certauth-service.log:
• 2024-02-21 18:25:53,736 GMT INFO certauth (ForkJoinPool-1-worker-4237) [-;127.0.0.1;13f9532b-a8b0-4a26-afbe-2f0564e7f68c;c2ad-***-83bb] com.vmware.vidm.auth.certificate.adapter.CertificateAuthAdapterBase – CertificateService authentication successful for user@domain.com retrieved from: upn
Looking into the esmanager.log i always see the same messages.
• 02/21 18:25:53,759+0000[jersey-client-async-executor-0]INFO request.BaseAuthentication[logMessage: 274][10.129.0.10][][Horizon][c2ad-***-83bb-***-d3f2-***-1ff2]: Authentication successful for user user@domain.com. Auth type: CERTIFICATE-AUTH
• 02/21 18:25:53,942+0000[nioEventLoopGroup-73-1]INFO response.SubmitAuthenticationResponseProcessor[processDocument: 133][10.129.0.10][][Horizon][c2ad-***-83bb-***-a107-***-bb55]: Authentication attempt response – error, user-sid:
• 02/21 18:25:53,942+0000[nioEventLoopGroup-73-1]WARN processor.XmlApiMessageProcessorUtil[persistFailedLoginAttempt: 546][10.129.0.10][][Horizon][c2ad-***-83bb-***-a107-***-bb55]: UAGW00108: Authentication attempt – FAILED, error code – AUTHENTICATION_FAILED, error message – Authentication failure, user message – This Horizon server expects to get your logon credentials from another application or server, not directly through the client login screen. If you usually access Horizon from another application, please launch that application.
• 02/21 18:25:53,942+0000[nioEventLoopGroup-73-1]INFO response.SubmitAuthenticationResponseProcessor[processDocument: 312][10.129.0.10][][Horizon][c2ad-***-83bb-***-a107-***-bb55]: Got error response for auth. Invalidating UAG session.
I have tried googling the error UAGW00108 with little to no success. The PKI itself is fine, I can use it for domain login in the same windows domain. The PKI works with the old versions of Horizon. When I try to use anything newer then 7.13 I cannot manage to get it working.
I was hoping to check with you if you have come across a similar situation.
Best Regards,
Rickard
In 8.12, go to Global Settings, Security Settings, Certificate settings, and check the box for UPN and Predefined Alternate Security Identities (legacy). Try again.
Hi Brad,
Thank you for the answer. I have now successfully connected to the Connection Server and logged in with my smartcard. After adding my smartcards CA to a truststore file on the CS (https://docs.omnissa.com/bundle/Horizon-AdministrationV2312/page/AddtheCACertificatetoaServerTruststoreFile.html) and following your instructions the smardcard logon was successfully made.
At least I have a different error at my Horizon Client “Error: A network error occurred”. The following error/warning messages are showing in “esmanager.log “.
06/07 08:14:01,199+0000[nioEventLoopGroup-19-1]ERROR networkcore.HttpsServerInitializer[operationComplete: 131][10.14.10.23][][][]: UAGE00999: Inb Ch : [id: 0x709a4ada, L:/10.14.10.22:6443 – R:/10.14.10.23:55434] SSL handshake with client failed
06/07 08:14:01,200+0000[nioEventLoopGroup-19-1]WARN networkcore.HttpsRequestRouter[exceptionCaught: 158][10.14.10.23][][][]: UAGW00083: [id: 0x709a4ada, L:/10.14.10.22:6443 ! R:/10.14.10.23:55434]: SSLException: Exception: OpenSslHandshakeException; Message: error:02000086:rsa routines::last octet invalid;
Best Regards,
Rickard
Hi Carl. Why a single nic is recommended for UAG deployment? Why not a dual nic for increased security of traffic separation?
One NIC forces all traffic to and from the UAG to go through a firewall.
Two NICs connected to different sides of the firewall might cause traffic to bypass the firewall.
Have anyone here seen an issue with UAG 2312 and an f5 Health Monitor issue?
I had issues with 2312 working with the f5 at all, both the Health Monitor and the UAG’s “Horizon Destination Server” couldn’t resolve. Rolled back to 2309 until I can figure out what changes I need to make to my .ini files. I had to add minShaHashSize=SHA-1 for it even to deploy 2312 in the first place but something else must be different/missing.
Just had this issue. Apparently old send and receive strings were deprecated. Oddly enough documentation everywhere says to configure using FQDN VIP but that didnt work for us. What did work for us was removing the FQDN VIP and just leaving it blank like below.
Send String: GET /favicon.ico HTTP/1.1\r\nHost: \r\nConnection: Close\r\n\r\n
Receive String: clientlaunch-default
Hi Carl.
Is there a way to have the UAG allow the user to select a domain/realm to use as their login ?
Currently, the Horizon connection server allowes the user to select a domain to use, because there is a trust relationship between all domains.
The UAG enforces RADIUS authentication to use DUO, so it does not show any domains.
I read something about it here, https://docs.vmware.com/en/Unified-Access-Gateway/2309/uag-deploy-config/GUID-EFEB0CEC-8556-44BA-835E-C956B97E9DE7.html but I can’t make anyu sense out of it.
I would greatly appreciate assistance on this matter.
Is Duo doing RADIUS only?
After RADIUS, then it can show the domain list. https://docs.vmware.com/en/VMware-Horizon/2303-and-later/horizon-security/GUID-FB9FE1B3-677D-4363-A7B0-66E939A56469.html
The “Send Domain list” is enabled, and it works if the user logs in directly on the Horizon server within the LAN.
But any remote user, is not shown a domain list, and the username they type, is sent in the RADIUS request and is evaluated under the current domain as set in the DUO config file.
If you reconfigure Duo to be RADIUS only (no AD auth), then UAG will ask for RADIUS first and then AD afterwards with domain list.
thanks, but can you please explain what you mean RADIUS only ?
is it something in the duo config file ?
will i loose my sync between Duo and AD ?
will the users have to enter their credentials twice ?
The Duo Proxy server has a configuration file. Inside the file you specify how RADIUS clients authenticate. One option is AD authentication. Another option is Duo only (no AD).
With Duo only, the first authentication prompt will be only Duo. The next authentication prompt will be AD.
with this config, on the first prompt, the password mat be incorrect, and the user still get’s a duo prompt on their device, pretty unsecure.
Hello,
I wanted to upgrade to UAG 2309 yesterday with OVF in VCenter.
“Unified Access Gateway (UAG) 20.09.1 for vSphere and Amazon AWS (Non-FIPS)”
I was really surprised when I noticed the offical OVF from VMware is self-signed and marked as invalid.
https://www.carlstalhood.com/wp-content/uploads/2015/09/image-14.png
Any fix or explanation for that?
Christoph
Most OVFs I’ve seen are self-signed.
Hi Carl,
thx for your fast response.
I’ve double checked with an OVF from 2306, that had a valid signature.
I’ve never noticed that issue with UAG OVFs before.
Christoph
Hello Christoph,
Are UAGs on OVF that are self-signed and have invalid signatures having operational issues?
I think that’s only for deployment. Once deployed, it’s a regular VM.
We were running UAG 2306 without issue. Updating to 2309 using the same INI file settings (only difference is pointing to the newer .ova file), we now get “Tunnel reconnection is not permitted” failure after authentication when connecting directly to the UAG. We are configured for load balancing (f5) and have source address persistence configured and all that, and the issue goes away if we roll back the UAG to 2306. Seems very specific to a change in 2309, but I can’t find what/where that might be. Any thoughts?
Not sure if related (probably?), esmanager.log is full of lines like this:
11/29 18:47:46,600+0000[nioEventLoopGroup-10-2]INFO networkcore.HttpsServerInitializer[initChannel: 141][][][][]: [id: 0x5690f2b3, L:/:6443 – R:/:46310]: opened channel, #open=2, total=31202
11/29 18:47:46,602+0000[nioEventLoopGroup-10-2]INFO networkcore.HttpsRequestRouter[channelRead: 187][][][][]: Sending bad request. Incoming request does not have valid host header: null, XFH: null
That might be monitor probes not including the host header.
What Tunnel URL is configured in Edge Settings? Are you using the same URL in Horizon Client? If F5 is terminating SSL, is the F5 cert identical to the UAG cert?
Tunnel External URL on the UAG is the load balancer/f5 URL: https://fqdn.loadbalancer.addr:443
In this case, I am not using the same URL in the Horizon Client as I am testing against the UAG directly (fqdn.uag.addr) to ensure it is working correctly before re-adding back to the f5 pool; this is the thing that works on UAG 2306 but not on UAG 2309.
f5 terminates SSL for the UAGs, and does use the same cert as the UAG itself. Cert has SubjectAltNames for both fqdn.loadbalancer.addr and fqdn.uag.addr.
I don’t think it’s a load balancer issue, specifically — the Horizon Client is bypassing the load balancer anyway by connecting directly to the UAG — but it may have something to do with how the UAG is configured to work with a load balancer. Since the settings are identical between UAG 2306 and 2309, and works with the former but not the latter, I have to assume there’s something new/different with UAG 2309, but I can’t find any documentation on new/updated configuration settings to address it. [Yes, I should probably open a ticket with VMware Support, but oof is that a painful experience.]
To test a single appliance, modify your HOSTS file to resolve the main FDQN to the single appliance IP instead of the load balancing VIP.
I wanted to share the solution to a VMware Support case we’ve had open for over two months. We are running UAG 2112 version and have issues with HTML clients (no horizon client) that connect fine, but if disconnected cannot ever reconnect. They get an error “cannot connect to Connection Server”. The original session would show up as a “problem VM” in the Horizon Console.
The temp solution was to disable the ‘Client Encryption Mode’ in the UAGs.
Feedback from VMware Support: (11/29/2023)
“The R&D team has this issue identified on UAG when HTML client on browser is refreshed and a fix would be made available soon. But for now you should be ok to use the workaround to have the Client Encryption Mode set to disabled.”
Im trying to migrate my 7.13.3 Horizon Environment to 2306 and I’m trying to setup the new UAG. I am at Horizon settings “proxy patterns” and it’s not letting me save stating the following.
Proxy Destination URL should not have a path.
I don’t see where the issue is.
Thanks!
NM it was the :443
Thanks!
hi, got problem when connecting externally through UAG. we are able to login to the external url using HTML Access, however, when connecting to the Virtual Desktop, it redirects to the Internal Connection Server fqdn, which of course not accessible externally, however, when I try to “Manually” replace the internal fqdn of the connection server with the external url (from the address bar) the Virtual Desktop shows up -which just proves that 8443 external and 22443 is open.
All Gateway option on connection server is unchecked (PCOIP, BLAST, etc.) as per your guide. Certificates are also valid
Hey Carl, thank you for your guide here. It was instrumental in getting the UAG deployed in my environment last year.
I ran into an issue with a recent Chrome update that doesn’t allow my users to use Chrome. They get ERR_SSL_PROTOCOL_ERROR when hitting my URL. All other browsers work fine.
My googling has said this is due to Chrome disabling SHA1 server signatures.
Are you aware of any way to disable SHA1 on the UAG? Everything I can find says I’m already using SHA256 or 384.
Thanks again for your guide and all of your hard work!
If you press on your keyboard to open the Developer Tools and then switch to the Security tab, does it give you more info?
No the security console just says “This is an error page”
This ended up being an issue with the FIPS version of the UAG. Deployed non-FIPS and it works just fine now.
Having same issue – works with Firefox. No go with Chrome or Edge.
Hi Carl,
I replace the UAG ssl certificate after cant access to UAG adminpanel
uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Try an incognito window or different browser. I usually don’t replace the admin certificate and only replace the Internet certificate.
Great guide and we’ve followed it ourselves for our environment. We’ve run into a snag and wondering if you might have some ideas what could be happening.
So if going fully HTML, you can login, pick a pool, in events database we even see the horizon system offering up a machine from the pool but it never loads in the broswer and we get a time out.
If using the view client, it kicks off the authentication, login completes on the SSO side and then it just sits at ‘authenticating’ never even see a pool.
What do you have configured for the Tunnel URL and Blast URL? Are the two URLs reachable from the clients? Is the firewall trying to terminate and inspect the traffic?
tunnel url and blast url are the same fqdn tunnel getting 443 and blast getting 8443. We have been able to get everything working if we disable the tunnel option (which makes no sense to me).
Sorry I would have updated sooner but I guess the email got sent to spam.
Is there a load balancer in front of the UAG? Is the load balancer terminating SSL? If so, does the certificate on the load balancer match exactly the certificate on the UAG?
Yes and yes. Vmware support so far has suggested completely redoing our SAML config because those are the errors showing up in the log (but only when we enable the tunnel) So i’ll be trying that today.
We’re using the “custom port” load-balancing method for our UAGs.
We have our “PCOIP External URL” set to: x.x.x.x:10412
PCoIP correctly uses TCP-10412 but it still tries to attempt UDP on 4172. Is there a way around that?
All the docs I found said 4172. None of them mention entering a custom port number.
We are having problems connecting from external to horizon connection using client application only but html works. However from internal network is working client and html.
FW–>ADC–>UAG–>horizon connection
From UAG to ADC giving 403 forbidden.
any idea?
Does the Horizon Client show the list of icons?
HTML is Blast only. Do you have PCoIP enabled in the Horizon Client?
Thank you Carl for responding!
No I dont get the icons from the horizon client externally, it spins until it gives a tunnel error.
no i dont have PCOIP enabled on horizon client.
HTML access through web is working from external and internal.
HTML access and Horizon client app works flawlessly from inside the networking with ADC—>UAG–>Horizone.
Tunnel error usually means that the cert on load balancer does not match the cert on the UAG. Or maybe your UAG Edge Settings for Horizon has the wrong Tunnel URL configured.
Hi Carl, but it has been the same settings for years the only difference is that we did is upgrade ADC and since then the horizon client failed to connect.
I opened a case with Citrix and they reviewed logs and did analysis with wireshark however they said that the only thing is dropping the connection is coming from Horizon.
They saw a 403 forbidden from UAG to ADC with the message saying Customer’s cyber security team are raising concerns of using VMware Horizon title and error banner, Hence removing it. 403 Error page forbidden.
they concluded that you need to talk with the cyber team.
However I have troubleshooted with Network team to eleminate the ADC and directly nat from FW to UAG and the horizon client app worked!
FW–>UAG–Horizon (the client worked).
I was running UAG1 on an old version and Vmware team told me to upgrade UAG from 3.2.1 (unsupported) to higher version which I did and still same problem, they will contact me on Thursday or Friday to troubleshoot. But i wanted to share here as your blog is the ultimate in the combination of Horizon, ADC +Vmware. 🙂
What ciphers are configured on the UAG? If you upgraded UAG and imported an old config, then you probably have old ciphers.
I thought of that too and an hour ago I replaced the old imported ones:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA
with the ones you have in your blog:
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
still same problem.
Vmware disabled Tunnel on Uag and enabled Blast on CS level it worked from the outside (i got the icons) however not able to login to any Machine(VM) due to proxy route issue.
Still not able to solve this problem we all believe its an ADC issue after a recenter major upgrade from 12.x to 13.x
Managed to solve the problem by temporarily disabling custom Log4jrules on ADC WAF level, that made Horizon client app works.
Replaced 2203 with 2306 UAG and re-imported json config. Verified connectivity to Horizon all green. Azure multi-factor authentication now failing. I get the the text prompts from Azure but then it immediately says access denied. Error on NPS server event log is
NPS Extension for Azure MFA: NPS Extension for Azure MFA only performs Secondary Auth for Radius requests in AccessAccept State. Request received for User domain\user with response state AccessReject, ignoring request.
Spent all day troubleshooting. Any thoughts or recommendations to resolve?
Did you enter the RADIUS secret correctly?
Also see https://kb.vmware.com/s/article/93796
I can’t enable TLS 1.3 in UAG 2306. Any reason why? and when it connects to the horizon server. Error: SSL23_GET_SERVER_HELLO sslv3 handshake failure.
I am from OPSWAT Company.
Isn’t TLS 1.3 enabled by default? Did you import an old config where it was disabled? Do you have TLS 1.3 ciphers, like TLS_CHACHA20_POLY1305_SHA256, in your cipher list?
Anyone having issues with the script deploying UAG with SSH on?
I’ve got these in my general file, but SSH still comes on
sshEnabled=false
sshKeyAccessEnabled=false
sshPasswordAccessEnabled=false
I have exactly the same bahaviour. Have you managed to disable ssh via powershell deployment of UAGE?
Hi Carl,
When users login to VDI portal they need to enter User name and AD password and then it prompts them for RSA token passcode. How can we change the order, i.e User name and Passcode and then AD password. Thanks
Do you have RSA configured on the UAG? If you set it to RSA + Passthrough, then RSA is normally asked first.
Hello Carl,
I’m trying to deploy UAG using the powershell script. However while setting the target getting the below error.
PS /home/VDIAutomation/UAG/OVF> ovftool vi://administrator@vsphere.local@10.191.82.3/d4pcijiltanzudc1/host/cluster1/d4pcijiltanzuesxi2.kyndryl.lab/
Enter login information for source vi://10.191.82.3/
Username: administrator%40vsphere.local
Password: ********
Error: Found wrong kind of object (HostSystem). Possible completions are:
PS /home/VDIAutomation/UAG/OVF>.
Any help on this is highly appreciated
Hi,
We have Horizon 8 2111 and UAG 2209 across 2 datacentres (upgrading soon). There is F5 GTM load balancing the DNS between 2 DC’s. Each DC has an NSX V NLB with 2 UAG members. We have Cloud Pod Architecture with 2 CS per DC, also behind their own local NSX V NLB. The UAG’s point to their local CS NLB. We have had issues with our previous config so implemented the above to overcome “Access Denied” errors where a user would authenticate/MFA on a DC1 UAG and then connect to secondary Blast on a DC2 UAG. I have enabled “Host Port Redirect Mappings” so the client connects direct to the UAG which has resolved the problem for most, but there are still “Access Denied” errors for some users. VMware believe it is now a client issue
“we suspect its a horizon client issue is- In the logs user is trying to connect to the UAG url , but after the SAML authentication the client is redirecting it back to the LB url which is causing the access denied error”
They have asked us to add a reg key to the Windows clients
DWORD: DisabledFeatures
Value: HideSecondaryServer
This has resolved for those testing but this is no good to non Windows OS. We also see the Horizon client populate with not only the manually added Horizon url, but also any UAG that they are directed to.
Any help would be appreciated as we have had Access Denied related errors from day 1.
Thanks
Did you ever come up with a solution for the HideSecondaryServer issue?
Apologies for the delay. No, VMware gave us the reg key for Windows to fix the “Access Denied” issue that was now caused client side, but the servers populating is still an open SR. They are looking to release a Mac client with the fix for “Access Denied”, but this issue is not fixed. We have had Access Denied when load balanced between 2 datacentres from day 1 and changing configs, deploying new UAG’s with new NLB’s with port remap just moved the issue elsewhere.
With DNS lb’ing make sure that your DNS record TTL is longer than what it takes a user to go through the entire authentication process.
We were able to solve the multi-vip/port load-balancing issue post Horizon Client 2206 by writing custom F5 iRules that look at the URI that’s passed from the Horizon Client after the SAML authentication is completed. The URI will contain the correct VIP instead of the load-balanced VIP.
Do you have a solution for the issue we have that users with Horizon Client newer then 2111 and UAG 2111.1 are getting a popup with the message “Logout requested by system” after 3 hours?
Make sure connection multiplexing is disabled on the load balancer. Make sure the UAG session timeout is set correctly.
Could you explain the logic around why having connection multiplexing enabled would cause the ‘logout requested by system’ message?
See https://my.f5.com/manage/s/article/K84429588
We did solve did issue. Something was wrong in the persistence profile. It was deployed with a jsession script for cookies. Resolved it with cookie-encyption etc.
We are using the NetScaler for load balancing the UAGs and connections directly to the external URLs of each UAG work as expected. Now that we’ve added the NetScaler to LB across our 4 UAG sites we are getting the random timeout error. The NetScaler admin here says that since we are using SSL Bridge mode we don’t have access to make the multiplexing change as well as some of the other suggestions I’ve seen. Any thoughts on where I could have him look.
Using an external VIP that is load balanced on the F5. The F5 points to the UAGs. The UAG each point to a ‘paired’ Connection server or to an internal VIP that poings to an internal F5 > both Connection servers?
Does either configuration prevent a Disconnect of established VDI sessions during maintenance? If so, at what point are the sessions disconnected, during connection server reboots or UAG reboots?
If you pair UAG to a single Connection Server and if that single Connection Server goes down then the UAG will drop sessions. However, if you point UAG to load balanced Connection Servers, then UAG should continue working until all Connection Servers are down.
You don’t need a connection sever once the client has made contact with the VM, traffic can flow direct from UAG.
Only new connections are effected if Connection server is down unless you have an internal f5 in front of them.
We do it this way so can bring CS up and down at will, we also use a cloud pod so it does not matter which one users connect to .
Try disabling all Connection Servers that a UAG can use and see what happens on the UAG. Usually the monitor probe goes down, which causes the load balancer to stop sending traffic to the UAG.
I get what you are saying, we have 8 and our 4 external kemps see all of them, and the CS have 4 more internal kemps in front of them. can’t think of an occasion when we would loose all 8 as they are spread between 4 different Datacenters .
That working from home budget was put to good use .
Hello Carl!
Great guide!
For the scenario you mentioned the UAG should continue work in case if the first Horizon Server is down, do I absolutely need a load balancer?
We inserted a common address for the two Horizon into the cert, and created a DNS record for it. Could that work?
If UAG points to a single Connection Server and if that Connection Server is down, then UAG will drop existing connections.
Are you asking about DNS round robin instead of load balancing? I have not tried it, but I suspect persistence and availability monitoring might be an issue.
Yes I asked about the DNS Round Robin. Thank you for the answer.
Really a good blog!
I have the following setup:
UAG in the DMZ
Horizon in the LAN
I want to connect through the UAG into the horizon client.
The setup works when I use username and Password.
It also works with single sign on when I connect through the Connection Server with smartcard.
When I set the uag to pass through and leave the connation server to smartcard, it fails with the error: Authentication Failed Smart Card or Certificate authentication is required.
What special setting do i need on the UAG / Connectionserver to work for smartcard authentication? In this scenario?
I’m guessing smart cards don’t work when you terminate SSL on the UAG instead of the Connection Server. Have you tried smart card on the UAG? https://docs.vmware.com/en/Unified-Access-Gateway/2303/uag-deploy-config/GUID-A311FD9F-29D2-4FB5-AEFC-1DFDB0E7881E.html
Finnaly it worked, there have been a issue with the correct private key on the saml provider in the uag. As a Hint for others convert the private key on the uag itself in the correct format and you need to edit the SAML config manual in a notepad++ in the correct one line format.
I still have a issue:
What works:
smartcard auth on the uag single sign on into connectionserver and VDI.
What i need is:
Smartcard auth AND Client Certificate auth on the uag with single sign on into connection Server and VDI.
On the uag i can only choose client cert & Passthrough.
The Problem with the passthrough is, that the connection Server cannot see the Smartcard of the user and gives the error smartcard needed.
Is there a way to configure maybe in a config file, client cert & smartcard? I saw in previous versions that it was possible to choose the “and” and “or” between the different options.
Hi Carl!
We have already configured our Netscalers to load balance the UAGs. Is there a benefit to replacing that (and using the same virtual IP I had used there) with this new built in feature? Are there pros and cons to it?
The built-in HA feature requires three public IPs. Load balancing only needs a single public IP.
Hi Carl,
I download versions 2212, I followed the tutorial, and added SAML connection with Azure AD.
I can connect with Azure AD to my UAG, but when it start to load my VM, I get an “Internal Server Error” from my UAG.
Working directly with the connection server.
Do you know why ?
Thank you !
Download the logs from the UAG and examine them. Or it might be an error from the Connection Server and you’ll need to look at those logs instead.
Is True SSO configured?
I got the same thing the issue related to the UAG not being able to ping the connection servers. Try adding your domain to the resolved.conf on the UAG.
Hi Carl
We have the following issue – Horizon 8.8.0 build – 21073894 and an UAG in the DMZ.
When we connect from exteral by Webbrowser for HTML5, the page will not be loaded correctly. It looks like the page do not loading the CSS-Designs. We only see a ugly HTML-Page.
Any idea?
Did you modify the default proxy pattern on the UAG?
Did you modify locked.properties on the Connection Servers to accept the FQDNs of your UAGs?
Hi Carl
I’m not sure, that I correctly understand what you mean.
On the the Connection Server I have created the following:
Paht: C:\Program Files\VMware\VMware View\Server\sslgateway\conf
File: locked.properties
Input:
checkOrigin=false
enableCORS=false
Is that correct? And what do you mean with proxy pattern on UAG?
Thank you 🙂
locked.properties looks good.
For proxy pattern, on UAG, go to Edge Service Settings > Horizon Settings and click More.
I have not modifyed this setting. At the moment is it the following: /|/downloads(.*)
Is that correct?
Hello Sam,
please make sure that the proxy pattern is configured correctly. It should be:
(/|/view-client(.*)|/portal(.*)|/downloads(.*))
Hey Ray,
Thank you!! It works with your settings! Great! THANK you Ray an Carl! You are amazing!
Dear Carl,
Thank you for the insightful setup. Really valuable work you doing for the community !
We having some difficulty with our current setup. Starting off with a double DMZ and UAG’s in HA with 3 NIC’s. We now at a point that we reduced down to a single UAG. We still have the exact same problem.
We got UAG version 2212 with the connection server version 2212. We using the UAG’s as a reverse proxy. When using Microsoft Azure as the IDP the landing page of the Horizon connection server loads correctly, however it does not redirect to the Microsoft Azure login page for IDP. We don’t see any failures in our firewalls logs. We bypassing the proxy for the Edge/reverse proxy (Connection Server is still going over the proxy though)
Do you have any initial ideas on how to solve this issue ? Maybe you can also suggest where the issue might be coming from, Connection Server, Azure IDP, UAG (Edge) or UAG (Reverse Proxy).
Look forward hearing from you.
Thanks
Roland
Hi all. Is there an automatic update option?
We have a lot problem with seg in 22.09 and 22.12 (javax.net.ssl.SSLHandshakeException: Failed to create SSL connection), but in 22.07 and earlier work fine after json import …
There’s this – https://docs.vmware.com/en/Unified-Access-Gateway/2212/uag-deploy-config/GUID-214DB846-2899-434F-8026-B129C34C7CF9.html
Any SSL termination between the client and the UAG? You can do a network trace to see the SSL Handshake to make sure there’s cipher agremeent.
Carl, thanks you !!!
Great, I’ll try to update.
No, not from client to the UAG, i see error in /var/log/vmware/docker/seg/active-sync-payload-reporting.log “2023-02-01 10:38:21.024+0000 servername.domain.com ERROR (vert.x-eventloop-thread-0) [c.a.s.l.ActiveSyncPayloadMapProvider] – Error while sending Active Sync payload to Console. Set log level as debug to see the payload.
javax.net.ssl.SSLHandshakeException: Failed to create SSL connection”
also curl -v https://*:443 to api and console and seg servers are ok.
We noticed that after upgrading to 2212 when we use sslabs to verify our server
We are getting the following.
Additional Certificates (if supplied)
Certificates provided 1 (2170 bytes)
Chain issues Incomplete
We do not get this on the 2111 using the same cert.
I do notice in the new admin console for 2212 there is a new option for gateway certificates in the horizon admin console however I can’t find any information in the documents if that would be the issue. Normally we just add the certs in the UAG admin console.
If you are uploading a PFX, make sure the PFX was exported with the entire chain.
Why would the updated version of UAG change the SSL report though? It gets scanned prior to the upgrade and no chain warning and then once the UAG is upgraded the chain warning appears. We are using the same PFX across the board.
Thanks for the guide Carl!
I used this to setup the 2212-deployment with PowerShell, but I stumbled across an issue with the SSLCert and SSLAdminCert:
I use the same pem-format key and cert-chain for SSLCert and SSLCertAdmin. I had to manually edit my key file by adding “RSA” in the BEGIN and END-Tags.
Otherwise the script throws the following error and stops:
Error: Invalid private key PEM file (pemPrivKey) specified. It must contain an RSA private key.
This however seems to stop the admin-page from accepting the key. The other services seem to run fine.
If I upload the cert manually via the admin-page after deployment, it only accepts the key without the “RSA” in the keyfile.
So the deploy-Skript enforces the RSA-Tags, but the admin-page of uag does not accept it.
Do you have an Idea on how to evade this?
You can use an openssl command to convert the PEM file to an RSA key file:
openssl rsa -in somefile.pem -out id_rsa
Thanks for your quick response!
My key file is in RSA format. A diff on my key before and after your command is empty. The deploy-script only accepts the key, if it has the format:
—— START RSA PRIVATE KEY——
…
—— END RSA PRIVATE KEY——
openssl creates the key with the format:
—— START PRIVATE KEY——
…
—— END PRIVATE KEY——
If I add the RSA to the keyfile as described the deploy-script accepts the files. UAG uses the cert successfully for its services. But the admin-page can not use the cert. When uploading the cert manually via the admin-page I have to use the key-file without “RSA”.
Fixed this issue by editing the “uagdeploy.psm1”.
It checks the key-files by searching for the string “*—–BEGIN RSA PRIVATE KEY—–*”.
I changed those occurences to “*—–BEGIN PRIVATE KEY—–*” and used my key file without the “RSA” in the tags (as openssl creates it).
Now the script deploys the appliance and both interfaces (admin and internet) use the certificate I specified.
Problem would be fixed if the admin-page of the UAG appliance accepted PEM private keys with “*—–BEGIN RSA PRIVATE KEY—–*” and “*—–END RSA PRIVATE KEY—–*”, which it currently does not.
Hello Carl!
Great guide, a real time-saver.
UAG “Proxy pattern” is not correct for version 22.09.
If you put /|/downloads(.*) in a blank field when configuring UAG for the first time it will not add default values to the list.
The correct way is to leave this field blank. After saving settings it is safe to add /|/downloads(.*) to the end of the list. It should look like this:
(/|/view-client(.*)|/portal(.*)|/appblast(.*)|/downloads(.*))
Thank you!
Thanks for pointing that out. I just updated the text and screenshot.