Omnissa Unified Access Gateway 2406

Last Modified: Aug 6, 2024 @ 1:24 am

801 Comments

Navigation

💡 = Recently Updated

Change Log

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).

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.
  • 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.
    1. Use the Select Version drop-down to select the version of Horizon you have deployed.
    2. Then open the downloads for the edition that you are entitled to: Standard, Advanced, or Enterprise.
    3. Scroll down the page to see the Unified Access Gateway downloads. You usually want the Non-FIPS version.
    4. Then download the PowerShell deployment scripts on the same UAG download page.
  •  

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:

  1. Download ovftool from Broadcom.
  2. If OVF Tool is already installed, then you’ll have to uninstall the old version before you can upgrade it.
  3. On the machine where you will run the UAG Deploy script, install VMware-ovftool-…-win.x86_64.msi.
  4. In the Welcome to the VMware OVF Tool Setup Wizard page, click Next.
  5. In the End-User License Agreement page, check the box next to I accept the terms and click Next.
  6. In the Destination Folder page, click Next.
  7. In the Ready to install VMware OVF Tool page, click Install.
  8. In the Completed the VMware OVF Tool Setup Wizard page, click Finish.

Create or Edit a UAG .ini configuration file:

  1. Extract the downloaded uagdeploy PowerShell scripts for your version of Unified Access Gateway.
  2. 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.
  3. A full explanation of all configuration settings can be found at Using PowerShell to Deploy Unified Access Gateway at Omnissa Docs.
  4. For any value that has spaces, do not include quotes in the .ini file. The script adds the quotes automatically.
  5. 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.
  6. 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.
  7. You can optionally enable SSH on the appliance by adding sshEnabled=true.
  8. For the source setting, enter the full path to the UAG .ova file.
  9. For the target setting, leave PASSWORD in upper case. Don’t enter an actual password. OVF Tool will instead prompt you for the password.
  10. 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
  11. Specify the exact datastore name for the UAG appliance.
  12. Optionally uncomment the diskMode setting.
  13. For a onenic configuration (recommended), set the netInternet, netManagementNetwork, and netBackendNetwork settings to the same port group name.
  14. Multiple dns servers are space delimited.
  15. 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.
  16. There’s no need to enter the .pfx password in the .ini file since the uagdeploy.ps1 script will prompt you for the password.
  17. proxyDestinationUrl should point to the internal load balancer for the Horizon Connection Servers.
  18. 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).
  19. 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.
  20. 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.

  1. Open an elevated PowerShell prompt.
  2. 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.
  3. Add the -iniFile argument and enter the path to the .ini file that you modified. Press <Enter> to run the script.
  4. You’ll be prompted to enter the root password for the UAG appliance. Make sure the password meets password complexity requirements.
  5. You’ll be prompted to enter the admin password for the UAG appliance. Make sure the password meets password complexity requirements.
  6. For CEIP, enter yes or no.
  7. For .pfx files, you’ll be prompted to enter the password for the .pfx file. Note: the .pfx file must be local, not UNC.
  8. 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.
  9. The deploy script will display the IP address of the powered on UAG appliance.
  10. Review settings in the UAG admin interface.
  11. 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:

  1. Login to the UAG at https://<Your_UAG_IP>:9443/admin/index.html.
  2. In the Configure Manually section, click Select.
  3. Scroll down to the Support Settings section, and then click the JSON button next to Export Unified Access Gateway Settings.
  4. 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.
  • 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.
    1. Use the Select Version drop-down to select the version of Horizon you have deployed.
    2. Then open the downloads for the edition that you are entitled to: Standard, Advanced, or Enterprise.
    3. Scroll down the page to see the Unified Access Gateway downloads. You usually want the Non-FIPS version.

To deploy the Unified Access Gateway using VMware vSphere Client:

  1. If vSphere Client, right-click a cluster, and click Deploy OVF Template.
  2. Select Local File and click Upload Files. In the Open window, browse to the downloaded euc-unified-access-gateway.ova file, and click Next.
  3. In the Select a name and folder page, give the machine a name, and click Next.
  4. In the Review Details page, click Next.
  5. In the Select configuration page, select a Deployment Configuration. See Network Segments at Unified Access Gateway Architecture at Omnissa Tech Zone. Click Next.
  6. In the Select storage page, select a datastore, select a disk format, and click Next.
  7. 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.
  8. In the Customize template page, select STATICV4, and scroll down.
  9. In the NIC1 (eth0) IPv4 address field, enter the NIC1 (eth0) IPv4 address. Scroll down.
  10. Enter DNS addresses, Gateway, and Subnet Mask. Scroll down.
  11. Scroll down and enter more IP info.
  12. Scroll down.
  13. Enter a Unified Gateway Appliance Name.
  14. Scroll down.
  15. UAG 2207 and newer let you specify the local root username.
  16. Enter passwords.

    • UAG 20.12 (2012) and newer let you specify Password Policy settings when deploying the OVF.
  17. Scroll down and enter the password for the admin user.
  18. 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.
  19. UAG 2207 and newer have an option to enable DISA STIG compliance, usually on the FIPS version of UAG.
  20. There’s a checkbox for Enable SSH.
  21. In UAG 3.9 and newer, there’s an option to login using a SSH key/pair instead of a password.
  22. Newer versions of UAG have more SSH options.
  23. UAG 2207 adds Commands to Run on First Boot or Every Boot.
  24. Click Next.
  25. In the Ready to complete page, click Finish.

UAG Admin Interface

  1. Power on the Unified Access Gateway appliance.
  2. 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.
  3. 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

  1. If you have previously exported settings, you can import it now by clicking Select in the Import Settings section.
  2. 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).
  3. It should say UAG settings imported successfully. If you don’t see this, then your .json file probably has a SHA-1 thumbprint.
  4. Press <F5> on your keyboard to refresh the browser.
  5. 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.
  6. In the top row labelled Apply certificate to, select Internet interface.
  7. Change the drop-down for Certificate Type to PFX.
  8. In the row Upload PFX, click Select and browse to your PFX file.
  9. In the Password field, enter the PFX password and then click Save.

Configure Horizon Settings

  1. To manually configure the appliance, under Configure Manually, click Select.
  2. Click the slider for Edge Service Settings.
  3. Click the slider for Enable Horizon.
  4. As you fill in these fields, hover over the information icon to see the syntax.
  5. The Connection Server URL should point to the internal load balanced DNS name (URL) for your internal Connection Servers.

    1. 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.
    2. On the Details tab, copy the SHA-256 Fingerprint. Note that SHA-1 thumbprint is no longer supported.
  6. In the Proxy Destination URL Thumb Prints field, type in sha256= and paste the certificate thumbprint.
  7. 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.
  8. Enable the three PCOIP, Blast, and Tunnel Gateways and perform the following configurations:
    1. 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.
    2. 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.
    3. For Enable UDP Tunnel Server, enable the setting.
    4. 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.
    5. 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.
  9. Then click More.
  10. 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(.*))
  11. Scroll down and click Save when done.
  12. 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.
  13. In your Horizon Connection Servers, the Secure Gateways (e.g. PCoIP Gateway) should be disabled.
    1. Go to Horizon Console.
    2. Expand Settings and click Servers.
    3. On the right, switch to the tab named Connection Servers.
    4. Highlight your Connection Servers and click Edit.
    5. Then uncheck or disable all three Tunnels/Gateways.
    6. HTML Access probably won’t work through Unified Access Gateway. You’ll probably see the message Failed to connect to the Connection Server.
    7. 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.
    8. 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.
    9. 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.

  1. In UAG Admin console, under Advanced Settings, click the gear icon next to System Configuration.
  2. At the top of the page, change the UAG Name to a friendly name. You’ll use this case-sensitive name later.
  3. Click Save at the bottom of the page.
  4. In Horizon Console, on the left, expand Settings and click Servers.
  5. On the right, switch to the tab named Gateways.
  6. Click the Register button.
  7. In the Gateway Name field, enter the case-sensitive friendly name you specified earlier, and then click OK.

See status of UAG appliances:

  1. Use a Horizon Client to connect through a Unified Access Gateway. Horizon Console only detects the UAG status for active sessions.
  2. In Horizon Console 7.10 and newer, to see the status of the UAG appliances, on the top left, expand Monitor and click Dashboard.
  3. In the top-left block named System Health, click VIEW.
  4. With Components highlighted on the left, on the right, switch to the tab named Gateway Servers.
  5. 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:

  1. In Horizon Console 7.10 or newer, go to Monitor > Sessions.
  2. 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.

  1. Upload Identity Provider Metadata.
  2. 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.
  3. For complete True SSO instructions, see https://www.carlstalhood.com/vmware-horizon-true-sso-uag-saml/.
  4. 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.
  5. For Azure MFA, see Sean Massey Integrating Microsoft Azure MFA with VMware Unified Access Gateway 3.8.

For RADIUS authentication:

  1. 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.
  2. Then in Edge Service Settings > Horizon Settings > More (bottom of page), you can set Auth Methods (near top of page) to RADIUS.
  3. If you scroll down the Horizon Settings page, you’ll see additional fields for RADIUS.
  4. In UAG 3.8 and newer, Passcode label field can be customized for MFA providers like Duo.
  5. 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

  1. UAG 3.8 and newer shows when the admin password expires in Account Settings in the Advanced Settings section.

  2. 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.
  3. Session Timeout is configured in System Configuration. It defaults to 10 hours.
  4. UAG 3.6 and newer let you add static routes to each NIC.
    1. Click Network Settings.
    2. Click the gear icon next to a NIC.
    3. Click IPv4 Configuration to expand it and then configure IPv4 Static Routes.
  5. 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.
  6. UAG 20.09 (2009) and newer can automatically install patches/updates when the appliance reboots.
    1. In the Advanced Settings section, click Appliance Updates Settings.
    2. For Apply Updates Scheme, select an option. Click Save.
  7. UAG supports High Availability Settings.

    1. 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.
      1. The High Availability feature requires three IP addresses and three DNS names:
        1. One IP/FQDN for the High Availability Virtual IP.
        2. And one IP/FQDN for each appliance/node.
      2. 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.
      3. The Virtual IP (and its DNS name) is only used for the High Availability configuration.
      4. The YouTube video High Availability on VMware Unified Access Gateway Feature Walk-through explains the High Availability architecture.
    2. Set the Mode to ENABLED.
    3. Enter a new Virtual IP Address which is active on both appliances.
    4. Enter a unique Group ID between 1 and 255 for the subnet.
    5. Click Save.
    6. On the second appliance, configure the exact same High Availability Settings.
  8. To upload a valid certificate, scroll down to the Advanced Settings section, and next to TLS Server Certificate Settings, click the gear icon.

    1. In Unified Access Gateway 2312 and newer, click Edit in the Internet section.
    2. In Unified Access Gateway 3.2 and newer, you can apply the uploaded certificate to Internet Interface, Admin Interface, or both.
    3. 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.
    4. Leave the Alias field blank.
    5. Click Save.

    6. If you changed the Admin Interface certificate, then you will be prompted to close the browser window and re-open it.
  9. Or, you can upload a PEM certificate/key (this is the only option in older UAG). Next to Private Key, click the Select link.

    1. 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.
    2. 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.
    3. Click Save when done.
  10. 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.

  11. 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.
  12. 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

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

801 thoughts on “Omnissa Unified Access Gateway 2406”

  1. Hi Carl, Was wondering if you could point me in the right direction. I have up and running UAG 2.9. The issue I’m having is with the TLS Server certificates. The UAG is a one NIC deployment sat in our DMZ, firewall controls internal/external access. DigiCert have generated two certs from the certreq I sent them. They have been sent to me in .crt format. The appliance is asking me to upload ‘private key’ and ‘certificate chain’ in PEM format. I have renamed the file to the PEM extension and tried to upload. The fields when I click ‘save’ turn red :(. Any suggestions / help to get the public facing cert working would be appreciated. Thanks.

    Reply

    1. Where did you generate the private key? If on IIS, you need to complete the certificate there first, and then export to PFX (UAG 3.0 can import the .pfx file). If a Linux box, then you need to get the private key from it and combine it with the certs you got from DigiCert.

      Reply

      1. Thanks for getting back to me Carl, I’m a bit of a novice when it comes to certificates, managed fine with the internal stuff. Not sure if this was the correct method but to summarize – the private key was generated via ssh session to the UAG. Created a configuration file, generated the CSR from the configuration file
        (WinSCP was used to upload config file / download the files generated) vdi.key and vdi.csr – were the files sent to digicert CA.

        The files sent back to me from Digicert are two .crt files and they have the following format;

        —–BEGIN CERTIFICATE—–
        MIIElDCCA3ygAwIBAgIQAf2j627Q4tyS8+8kTANBgkqhkiG9w
        MQswCQYDVQQGEwGA1UEChMMRGlnaUNlcnQgSW5jMR
        ………….
        —–END CERTIFICATE—–

        I have now combined the certs, however is it the formatting that is preventing this from working? I’ve read about One-Line PEM Format. Is there some tool or command line utility I’ve missed.

        Reply

          1. The last thing you want to do is upload your certs to test. You may have just given away your Private KEY!

        2. The One-Line format is only needed for REST configuration. Otherwise, my instructions starting with step 28 in the Admin Interface section should detail how to upload the certificate and the format for the files. You upload the .key file. And you upload the .cer file with the server certificate on top and intermediate certificate below it.

          Reply

  3. Has anyone experience teh issue while deploying 2.9 where the root or admin password do not work. I’ve checked to make sure my password complies with the requirements, but it doesn’t matter whether I use the powershell script or the web client to deploy the appliance. The password won’t work at all

    Reply

  4. Hello Carl! Your blog is excelent!

    I have a cuestion for you. I have installed two Access Point 2.8, with one nic each. Everything works as expected, but today when have tryed to enter to this address https://myipaccpoint:9443/admin/index.html in the both server, always have the same error:

    Whitelabel Error Page

    This application has no explicit mapping for /error, so you are seeing this as a fallback.

    Thu Mar 30 14:16:38 UTC 2017
    There was an unexpected error (type=Not Found, status=404).
    Not Found

    Could you please help me? This is the first time I have encountered this error.

    Thanks!
    Marcelo.-

    Reply

  5. Hi,

    I’ve configured AP as a reverse proxy for VIDM, however it REDIRECTS to VIDM’s internal FQDN. Any idea why this is happening? Based on my understanding, it should stay at the AP’s external URL all the way so that it can be externally resolvable, correct?

    Really need some help here!

    Thanks

    Reply

  6. Hi Carl

    Few updates
    1. Not much linux skills are needed to deploy so following could be removed
    “However: It’s Linux so you need some Linux skills.”
    2. Version section could be updated
    UAG ver are backward compatible with Horizon version and min version supported per the interop matrix on 6.2.x is AP 2.5.1 and HZ 7.x is UAG_v2.9
    IDM also min version now supported is 2.8.1

    3. Firewall section could be updated,with the info from
    http://pubs.vmware.com/accesspoint-29/index.jsp#com.vmware.access-point-29-deploy-config.doc/GUID-F197EB60-3A0C-41DF-8E3E-C99CCBA6A06E.html
    4. Blast enhancements are only available on UAG and Not on Security server
    5. VMW recommends using either Admin UI or Powershell scripts to deploy UAG, so some of the sections for AP2.0 using REST API config could be updated

    thanks
    Vish

    Reply

    1. Hi Vish, thanks for your recommendations.

      1. I changed the Linux comment to restrict it to Troubleshooting only.
      2. The Interoperability Matrix shows that only two versions of Horizon are supported with UAG 2.9. Maybe the matrix hasn’t been updated yet? And I don’t see any Identity Manager with 2.9.
      3. I linked to the Pubs article, but I didn’t see any differences with my firewall rules list.
      4. I wasn’t aware of that. I found some confusing documentation and linked to it.
      5. Correct. I try to avoid removing old content in case somebody still wants to read it. But each of those sections links to earlier sections that use the preferred configuration methods.

      Reply

      1. #2 About version support, as per current matrix min version of UAG is 2.7.2 for Horizon 7.x and for Horizon 6.2.x is UAG v2.5.1
        For Identity manager min version of UAG is 2.8.1

        Reply

  7. Hi Carl,
    did you configure AP 2.8 as a reverse proxy for identity manager ? I do not find it, and proxy pattern found on the documentation does not seems to work. I get error: “ERR_TOO_MANY_REDIRECTS”.

    Thank you

    Reply

  9. Question, how do you get to the GUI on the AP if there is only a single NIC and it is in our DMZ? I am unable to access it from a device that is internal even when the AP is configured to my internal DNS servers.

    Reply

  11. Hi Carl
    Very Nice writeup. Article needs some updates
    1. Another benefit of AP over security server is additional security with DMZ authentication
    Some of the Authentication methods supported on AP are RSA SecurID, RADUIS, CAC/ certificates

    2. “No management GUI. Use REST instead.” — Starting APv2.8 there is GUI available

    3. Versions – Minimum version to use AP is Horizon View v6.2 and upwards.
    – APv2.7.2 and upwards single image could be used for Horizon and IDM
    – Latest version of AP are backwards compatible, please refer the compatibility matrix for each version

    4. VMW recommends using either Powershell scripts or Admin GUI to deploy AP.
    demo video link is out dated so could be removed

    Reply

    1. Looks like I should have removed a couple items when updating for 2.8. Let me know find anything else. Thanks.

      Reply

  12. Great article! Glad to see you keep it up-to-date with the new versions. 2.8 is so much easier to deal with than 2.0.0…

    Reply

  13. Hello.

    I have a problem to acess my IDM throught the Access Point.
    I don’t have the login page, il my firewall I saw a flow that confirm that the HTTPS request is forworded to the IDM.
    My view horizon client do not have any problem through the Access Point

    Thanks for help

    Reply

  14. After struggling with Access Point 2.8 and the new GUI, we found out that there are multiple bugs. Importing SSL certificates (PEM files) using the interface does not work correctly. Use the swagger to import or create a custom ini file to deploy Access Point 2.8 through Powershell. Don’t depend on the GUI.

    Another problem we have seen is to disable 2 factor authentication after configuring this in the GUI. The GUI won’t allow you to disable these settings.

    VMware confirmed this after a 2 day investigation.

    The biggest problem we ran into is to create the PEM files including the VIP. There is no direction / no correct information from VMware how to do this.

    Reply

    1. Could you please explain what you needed to do to get it to work. You talk about the biggest problem being the VIP PEM files. If you could write up what you had to do that would be greatly appreciated.

      Thanks,

      Reply

  15. Lots of useful stuff Carl!
    Still we run into a Blast problem we can’t figure out.

    We’ve deployed an EUC access-point 2.8 having troubles with the blast part. Blast isn’t working while on the connection server in the locked.properties file checkOrigin is set to false.

    1) The connection servers 7.0.3

    2) PCoIP sessions are working

    3) Directly accessing VDI through Connection Server. Direct through the connection server works.

    4) Access VDI over Blast, when directly accessing VDI through Connection Server works

    The screen stays white. I found out that i can’t telnet to port 8443.

    Reply

        1. I’m experiencing this same thing with 2.8 and Horizon 7.0.3. Previously my method of testing whether or not blast was working was by navigating to the name with port :8443 and expecting “Missing route token in request”. Doesn’t seem like that’s working.

          Reply

        1. This is huge! I ran into the same issue and can confirm that the only way I could get blast working was to deploy the access point ver. 2.8 with the powershell script at the link provided above. I stood up the initial AP from vSphere web client by deploying the ova. Everything worked fine except for blast, so I resisted redeploying from powershell and wanted to troubleshoot the issue. VMware support seemed very hesitant to troubleshoot the AP and steered me towards redeploying with powershell so this is definitely a known issue. Its disappointing that its not more widely publicized in their documentation. Their documentation list deploying the ova through the web client and vsphere client as supported install methods. It is further disappointing that we get these new versions of software that clearly haven’t been fully tested. Come on VMware!!!

          Reply

          1. Agree 100% – very little on the VMware communities either about the need for the powershell deployment.

    2. Hi Peter You also need to to open port 22443 https from AP to the remote desktops, and for the connection servers tunnelling and blast secure gateway should not be enabled in view admin console settings

      Reply

  18. Hi Guys,

    Seeing a very strange issue with the latest version of accesspoing and wondering if anyone can shed any light and help.

    I have blast working with out an issue

    The issue comes when connecting over PCOIP. For some reason this gets a black screen on connection. From the switch we see a deny to the internal IP address of the device connecting through the access point.

    Firstly how does it get this address and secondly any idea how to fix this?

    Reply

    1. We have to allow 50002 out bound from the VDI’s however when you look at the deny’s on the switch as said above it is the internal IP of the device connecting in; must build some sort of VPN?

      Reply

  19. Hi Carl,

    I have an Access Point 2.7.2 integrated in a vIDM 2.7.1 portal. This AP acts as “proxy” for RDSH apps (that are served by an internal connection server configured). Internally it’s all OK. Externally, the user passes throw AP.

    If I delete in the Edge service configuration the authmethod, passthrow wins and the user see the RDSH app.

    If I configure an authentication method (I would like RSA + SAML), it asks RSA and after a while says “Failed to connect to Connection Server”.

    I think the problem is in “trust” between AP and vIDM. I have tried to configure SAML Metadata, etc., but I’m not sure which are the correct steps. Can you help me?

    Thank you.

    Reply

  20. Hi Carl,

    I have configured an Identity Manager 2.7.1 with two Access Points 2.7, one vs an RDSH farm AP1, (throw an Horizon View 7.0.1 Connection Server) and the other vs an Horizon View 6.2.1 farm (a.k.a reverse proxy and connected externally throw Security Gateways). From external, users talk with RSA servers to login and see vIDM portal

    I have applied the public SSL certificate and now I can view my vIDM portal from Internet. Internally all works fine. From Internet when I click on an icon on my portal (RDSH app or VDI desktop) I receive an error like “there is an error launching the resource. Contact your administrator”.

    Have you ideas?

    Thank you

    Francesco

    Reply

  21. Hi Carl, I really appreciate comprehensive information for setting up AP’s. I have set up AP 2.7.2 in our test environment and would like to configure Azure MFA. Can you please share some details for setting up Azure MFA.
    Cheers

    Reply

  22. Hey Carl, i have a requirement where i have 6 internal connection server which is running behind the VIP of netscaler. i have a problem as per my configuration our users are hitting to abc.test.com for internal horizon access and i want to set the same url for accessing the horizon view from outside through access point.Do i need to configure anything more for that ?

    Thanks
    Mijan

    Reply

  25. I have been tweaking the security of my access point appliances and have discovered that by eliminating the 128 bit cipher, I am able to now get a score of 100 on the cipher strength portion of the SSL Labs test. My config is below if anyone wants to use it. It makes little to no difference on the compatibility. I’m still only getting a 90 on the key exchange score which is preventing me from getting an A+, so I’m going to keep working on that. Please let me know if anyone has been able to get a higher score there. FYI I am running the new 2.5 version of the appliance that was released with Horizon 7

    {
    “locale”: “en_US”,
    “adminPassword”: “*****”,
    “cipherSuites”: “TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384”,
    “ssl30Enabled”: false,
    “tls10Enabled”: false,
    “tls11Enabled”: true,
    “tls12Enabled”: true
    }

    Reply

    1. One small tweak and I was able to get an A+. I just disabled TLS 1.1 which is fine if your users connect from the latest Horizon client and web browsers. The config is below:

      {
      “locale”: “en_US”,
      “adminPassword”: “*****”,
      “cipherSuites”: “TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384”,
      “ssl30Enabled”: false,
      “tls10Enabled”: false,
      “tls11Enabled”: false,
      “tls12Enabled”: true
      }

      Reply

  26. Hi Carl, why my postman refuse to show privateKeyPem and cerChainPem in a single line? I’ve already format via notepad++, it’s “Dos/Windows” format and after replace “\r\n” to “\\n”, it’s showing one line in notepad though.

    Reply

  27. Carl, I wanted to send you a big THANK YOU for this blog post. Following everything here I was able to get my access point up and configured properly with a third party cert. I’m also getting an A on the SSL checker. Hats off to you on this extremely helpful post and all the work you put into it!

    Reply

  28. I have NetScalers, 2 Access Points in the DMZ and 4 Connection Servers Internal [2 for internal users / 2 for use w/ access points].
    Do I need to setup a VIP for the 2 Connection Servers that are being used with the Access Points? If yes is it just 443 that needs the VIP?
    I have read the “Horizon View Load Balancing – NetScaler 11”, it’s a mash up of Access Point, Connection Server internal / paired, and Security server configurations. When it says Internal Connection Servers i’m not sure if you mean for internal users or to use with Access Points.

    Reply

    1. Yes to load balancing Internal Connection Servers for Access Points. Access Points point to the load balancing VIP.

      Access Points talk to internal Connection Servers in the same manner as internal clients. You can use the same Connection Servers for both internal users and Access Points. No more pairing needed.

      Reply

      1. Awesome thank you for the quick reply and all the help both here and on the Citrix forums!

        I’m using the second set of Connection Servers so we can use tags to filter.

        Reply

  29. Hey Carl,

    So one more question for you. I have this all up and running now thanks, My issue is with the HTML access (Blast)

    I have the following setup:

    {
    “identifier”: “VIEW”,
    “enabled”: true,
    “proxyDestinationUrl”: “https://FQDN of server:443”,
    “proxyDestinationUrlThumbprints”: “sha1=XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX”,
    “pcoipEnabled”: true,
    “pcoipExternalUrl”: “External IPAddress:4172”,
    “blastEnabled”: true,
    “blastExternalUrl”: “https://vdi.DomainName.com:8443”,
    “tunnelEnabled”: true,
    “tunnelExternalUrl”: “https://vdi.DomainName:443”,
    “proxyPattern”: “/”,
    “matchWindowsUserName”: false,
    “gatewayLocation”: “External”,
    “windowsSSOEnabled”: false
    }

    Internally when you go diretly to the serverFQDN and launch HTML access everything works great. However when accessing the HTML access from the access point an error comes up saying “Failed to connect to the Connection Server.” Now I have seen this before and its related to the settings in the view connection server URL’s (now currently unticked) If I change them to point to vdi.DomainName.com and then restart the connection server, and untick them again the access point works but this intern brakes internal access. Mainly because to avoid split brain dns the internal domain is different to the external domain. I can of course add the external domain internally to the DNS server and make this work but I was trying to avoid this and thought the access point would allow me to get away with this. Any thoughts?

    Thanks

    Reply

    1. Sorry for repeating some of the above but thought I would update with more information and see if anyone (looking at you carl :P) has any ideas or suggestions.

      I seem to have a lot of issues with the access point, so for now think I am going to go back to security server, then continue to play with this to understand it more as there seems to be a few things that are a bit strange. Unless you have any thoughts on how to fix them.

      My network setup is as following:

      Internet—-Firewall—-EUC—Firewall–ConnectionServer

      the domains are as follows

      External Domain.com
      Internal ad.domain.com

      I was trying to use the EUC to avoid having multiple connection servers for different authentication requirements.

      From external we need dual authentication and internal we just need AD authentication.

      We have a older setup working with secserver–connectionserver1 and connectionserver2

      I could use that model and will work but it seems the access point is meant to work in the way we need and would make more sense.

      The current configuration of the access point is as follows:

      {
      “identifier”: “VIEW”,
      “enabled”: true,
      “proxyDestinationUrl”: “https:/connectionserver.ad.domain.com:443”,
      “proxyDestinationUrlThumbprints”: “sha1=XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX”,
      “pcoipEnabled”: true,
      “pcoipExternalUrl”: “XX.XX.XX.XX:4172”,
      “blastEnabled”: true,
      “blastExternalUrl”: “https://vdi.DomainName.com:8443”,
      “tunnelEnabled”: true,
      “tunnelExternalUrl”: “https://vdi.DomainName:443”,
      “proxyPattern”: “/”,
      “matchWindowsUserName”: false,
      “gatewayLocation”: “External”,
      “windowsSSOEnabled”: false
      }

      The view connection server before unticking the settings where configured:

      HTTPS Tunnel: https://connectionserver.ad.domain.com:443 — this is now unticked

      BLAST Gateway: https://connectionserver.ad.domain.com:443 — this is now unticked

      I have installed the wildcard certificate as well. uploaded as per the guide above.

      ——————————-

      Connecting to the Access point over HTTPS works and the correct certificate is displayed but when clicking on HTML access you recive an error “Failed to connect to the Connection Server.”

      To fix this I need to go onto the connection server and change the

      HTTPS Tunnel: https://vdi.domain.com:443

      BLAST Gateway: https://vdi.domain.com:443

      restart the services, then untick them and restart the services again.

      This then allows https access to work. So ok I can live with that and I can even add a DNS entry for vid.domain,com internally so clients will work.

      It does mean you cant login to the admin portal using the severname only localhost and the vdi address.

      Question 1: is this by design or a bug?

      ——————————————————-

      I have a strange issue with certificate

      On my phone using the horizon client the certificate is fine.

      From a PC or a thin client get a invalid certificate. HTTPS from anywhere the certificate is fine. Is this because the vdm certificate on the connection server is not vdi.domain,com?

      Sorry for the long question.

      SV

      Reply

      1. We needed the same thing “From external we need dual authentication and internal we just need AD authentication.”

        I did this by doing the following –
        4 Internal Connection servers
        ALL 4 are in the same group, they all replicate changes.
        The nice thing is 2 factor is PER Connection Server, not per group.

        view.domain.com resolves internally to the VIP on the netscaler to these two connection servers –
        CC 1
        CC 2
        These two do NOT have two factor enabled

        These two resolve to “viewext.domain.com” internally, also a VIp on the netscaler (That no one uses internally)
        CC 3
        CC 4

        The external dns view.domain.com then points to the VIP of the netscaler that points to the 2 access points, that then point to the VIP of the netscaler that points to the two CC servers (CC 3 and CC 4) that have two factor enabled.
        We use Azure MFA on-prem, works awesome btw…
        (Traffic flows – ASA FW – “Netscaler VIP for VM AP1/2” – NS-VIP for CC3/4 )

        I used an internal CA (domain.pri) and made a SAN cert for server1.domain.pri server2.domain.pri view.domain.com etc… I installed this on all 4 servers internally.
        I then used the Netscaler’s to VIP’s (view.domain.com) to use a Public wildcard cert to get SSL working.
        After I configured the VM AP’s for the correct thunbprints, IP’s etc. all works excellent!

        Carl can probably make sense of this, if I need to explain further I’ll try.

        -Aaron

        Reply

        1. Thanks Aaron,

          We are just using 1 connection server and 1 access point with no load balances for now.

          I have it working now:

          everyone internally and externally use vdi.domainname.com, internally it goes directly to the connection server and externally to the access point.

          Everything seems to be working pretty well in this setup. Now all I need to work out is how to setup DUO as a secondary authentication through the access point.

          Reply

  30. Hi Carl,

    Have you had any experience with multi Nic setup?

    I have been trying this for a while now with some major issues. I am actually going to test this in a 2 Nic setup and see if the issues persist. However in the current setup (3 Nics) there are no end of issues.

    To start I cant actually access either the main page or the API. After investigation and looking at the routes the device after deployment only configures one gateway for one of the networks at random. This obviously means that when trying to route from different subnets to different parts of the EUC it does not work. If I add more routes it breaks another part, its a never ending cycle.

    Even so when I do get routing working on the API side for example I still cant actually load anything from the device testing out the following URL: https://DeviceIP:9443/rest/swagger.yaml

    I tried adding the routes in manually and as I add a default route for a interface, one of the other interfaces stops working. I have tried to set the routes with different metrics, But that did not make a difference.

    Ill update after trying the two network setup. If you have any thoughts on this please let me know. It seems the device just does not work as advised from VMWare.

    Thanks

    Reply

    1. I’ve only done Single NIC. I can’t think of any benefit to multiple NICs. But I can think of security implications of multiple NICs.

      Reply

      1. We need at lease two I think as we need it to sit one leg in the DMZ and one on the internal Network rather than opening the DMZ up to the internal network.

        However I am not sure this design is actually going to work as the device does not seem to be able to handle it.

        I will put it on a single NIC and configure the firewalls either side.

        Thanks for the thoughts

        Reply

        1. The problem with dual-homing is that you essentially bypass the DMZ-to-internal firewall. That seems less secure than making your DMZ-to-internal firewall inspect all traffic coming from the Access Point.

          Reply

          1. When I thought about it like that with my network engineer that’s what we thought.

          2. So now I have this on a single NIC I still cant get access to anything. The pass-through or the rest API. Any ideas on trouble shooting, I can ping the device.

          3. That usually means the password isn’t secure enough or there’s a problem with what you typed in during the OVF deployment. View the file /opt/vmware/gateway/logs/admin.log.

          4. Thanks Carl,

            I did not know where that log was and you where correct.

            Thanks,

    2. I found a post on robbeekmans blog about using a program on the appliance called yast2.
      Made adding static routes super easy.

      Reply

  31. Hi Carl,

    I’ve fallowed your instruction and everything works fine, except HTML Access. I disabled ‘origin check’.
    When I trying to access https://hv.myportal.com/portal/webclient/index.html#/ via Access Point, I get user and pass input box and then error “Failed to connect to Connection Server”.

    Direct connection via Connection Server works fine.

    Any guess what might be wrong?

    Reply

    1. It’s working for me. Do you have the Blast Gateway enabled on the Connection Server? If so, try disabling it.

      Reply

      1. Nope.

        It’s unchecked.

        On AP’s esmanager.log there is such NullPointerException

        04/28 11:32:59,042[nioEventLoopGroup-31-2]ERROR proxy.HttpsProxyRequestHandler: Error during request interceptor invocation
        java.lang.NullPointerException
        at com.vmware.euc.gateway.edgeservice.sdk.session.Session.hasCookie(Session.java:163)

        Reply

        1. If you use Access Point 2.5 you will have to use english version of windows server for the connection server.

          Reply

  33. All I have to say is THANK YOU. This article was a huge help in getting this useful, but obtusely configured appliance up and working. I’m not sure I would have succeeded without it.

    Reply

  34. Hi Carl, Thank you for your post, its very helpful. Is there a chance you can provide some guidance on securid-auth RSA configuration? especially in the file conversion and post.
    Thank you

    Reply

    1. My plan is to do RADIUS. I’ll have to consider RSA since I currently don’t have it in my home lab.

      Reply

      1. Hi Carl,

        I have a question on RADIUS, I have this setup and working in terms of logging on through the access point. However the problem I have is that the user is then prompted to type there credentials again when it hits the connection server. Obviously I don’t want this to happen. I really want the access point to pass the authentication through meaning I don’t have to have two connection server (1 for two factor (external) and 1 for standard access (Internal))

        There is no clear information on this in the documentation. I was looking at when doing smart card access to make the pass through work you need to setup a fake SAML configuration. Do you need to do the same thing or something similar for RADIUS?

        Any ideas are welcome, while I continue to research.

        Thanks,

        Reply

          1. I was just reading that link actually, However I am getting a strange issue.

            I had it set to:

            “windowsSSOEnabled”: true,
            “authMethods”: “radius-auth”

            Originally so it would just use the radius authentication.

            Once radius works and logs in and then my user is presented with the standard logon page. I want it to pass the logon.

            I have tried:

            “authMethods”: “radius-auth && sp-auth”
            “authMethods”: “radius-auth || sp-auth”

            all with the same effect. Any idea on what I am missing? I would have thought it would have logged strait in.

            Thanks

          2. I think they are missing the password-auth option? Think thats the one I need to use after radius?

      2. Any other thoughts on the bellow, this is the last piece in the puzzle.

        I have tried a lot and there does not seem to be an obvious reason why the user is being double promoted. Its as if the details are not being passed through once they are authenticated against the radius setup.

        Basically I am trying to do all the authentication on the Access point,

        Duo then either pass through the details for login or active directory authentication as a secondary,

        I feel like I am missing something but not sure what.

        Thanks,

        Reply

        1. I actually have sorted the issue I was using a incorrect setting on the proxy service for Duo.

          Thanks to everyone especially Carl for helping me through this setup and learning curve 😀

          Reply

          1. Hello! Can you go a bit more into detail on this? We are having the same issue with smart card auth. The user logs in via smart card but then is prompted for username/password. What is this proxy service for Duo you are mentioning?

          2. Hi,

            I’m struggling with the same issue, Radius works as expected, sso and sp-auth is configured, but I still get the login prompt for the AD information.
            Any hint where to look in to finde the cause of the double prompt?

            Thanks
            Fredy

  35. Hei, great job, really easy to use and to share guide. I suggest you to add one sentence in troubleshooting area – Also check if vmware_ap_supervisord service is started.

    Reply

  36. Hi Carl,

    Is multiple nics setup secure than single nic? I thought single will be more secure as traffic need to go through the firewall. I just want to see what you view is. And I couldn’t find any documentation from VMware support their multiple nics setup argument.

    This is what VMware recommended.

    “Using three network interfaces is the most secure option. With a third NIC, external, internal, and management traffic all have their own subnets.”

    http://pubs.vmware.com/horizon-7-view/index.jsp?topic=%2Fcom.vmware.horizon-ap.deploy-config.doc%2FGUID-3055F669-7CC3-4F12-8CBF-F144854C471A.html&resultof=%22POC%22%20%22poc%22%20

    Reply

  37. Carl, Great work on these articles!

    i am wondering how do you monitor your Access Points, we had an issue today where Authenticaiton via the client would hang, but were able to connect via HTML

    Looking at ways to avoid this if we can

    Much appreciated
    james

    Reply

  38. Carl, Great write up. I have a question regarding syslog. I have the basic OS syslog forwarding to my syslog server, but not the logs specific to Access Point. Syslog-NG is not my strong suite, do you have any write ups to get those logs out to a remote syslog automatically?

    Reply

  39. Thanks for the awesome walkthrough. I’m having an issue where I get everything set up, SSL certs are applied correctly, I configure View to turn off tunneling, etc on the connection server, but I can’t connect to my View instance via the access point. I log into HTML access, select my virtual desktop, click it, but get a connection refused error from Chrome or IE. Have you run into this before?

    Reply

  40. I am having a strange issue where the Access point will not tunnel Blast traffic but PCoIP and RDP are working. Have you encountered this? I have a second Access point that is working fine but I cannot see any differences between them except the one that is not working has a cert for the specific external url and the subject alternative names are the names of the AP and the one that is working only has a cert for the server itself but then when users go to use the url they get a cert error because the names don’t match. I cannot seem to win here.

    Reply

    1. FYI this was resolved when we replaced the certificate with a cert that only contained the URL and did not contain subject alternative names of the access points.

      Reply

  41. Carl,

    I do the SSL cert piece and I did this before in our POC. Now for whatever reason I push the cert, and it reflects on the page at /rest/v1/config/certs/ssl but the website still shows it’s using the self signed. How can I fix this?

    Reply

      1. Ok, that’s probably my issue. I’ve been expecting the certificate to show at the 9443 pages. I’m still waiting on FW configurations before I can test the redirect all of the way down to our internal machine.

        Reply

  42. Great article and it will certainly help once I finish upgrading to view 6.2. After you finish deploying the access point, do you simply remove the existing security server from view administrator?

    Reply

    1. proxyPattern defines the URLs that are forwarded to View Connection Server. Anything not in this list will be ignored. The appliance already has default patterns for /broker and /xmlapi so there’s no need to include them here. /downloads is included so users can download the Horizon Client from the Horizon 6 Connection Server.

      Reply

      1. I appreciate the help you are providing! I set proxy pattern to “/|/downloads(.*)”. What else do I need to do? Do I need to upload the client to a certain directory? Do users go to myconnserver.corp.com/downloads/ to access the clients?

        Reply

  44. So it seems like I need a third load balancer config now… let me know if I am just wrong here. In the environment I am building they want to use RSA for externally connecting users. This forces me once again to have separate collection of connection servers for internal and external access. So I have the load balancer for the internal users to the two internal connection brokers… no problem there. I have the load balancer for the external users to hit the two access points and since the access points can now communicate with both the connection servers that have RSA enabled I need a third url and a third load balancer between the access points and those two connection servers? Or am I crazy? Or I can stick with the old one to one relationship between the security server (now Access point) I assume on that scenario the Access point is smart enough to reject traffic if its connection server is down?

    Reply

    1. I can’t think of any reason why you can’t point Access Point to a single Connection Server. But you’d need to configure your Access Point load balancer to monitor the RSA-enabled Connection Server too so if Connection Server goes down then the “paired” Access Point is also taken down. It’s probably easier to just load balance the second pair of Connection Servers and point the APs to that VIP.

      Reply

  45. Hi Carl,

    Have you tried a 2-arm or “2 NIC” deployment with the Access Point? Especially configuring routing for the appliance?

    cheers
    Vinay

    Reply

    1. I have not. I question the benefit of that configuration. With two-arm, you’re trusting the appliance to provide firewall services between the two security zones. Most enterprises prefer to use real firewalls for that purpose and thus one-arm is the more secure approach.

      Reply

  46. Carl,

    How would this work if internally I am using a Microsoft CA (domain.local) for my connection servers and externally use a Public CA for the .com certificate? What cert would i push with the put command, and what thumbprint should i use?

    Reply

    1. You upload whatever certificate that matches the name users will enter to access Horizon View remotely. Typically it’s a certificate that is signed by a public CA.

      The thumbprint should be from whatever certificate is installed on your View Connection Servers or load balancer. If you have multiple View Connection Servers then you have a load balancer with a cert on it and that’s the thumbprint you need. I think you can also enter * as a wildcard to trust all thumbprints.

      Reply

      1. Hi Carl,

        Rightly so you can indeed enter * into the thumbprint however it is very much frowned upon. From the latest VMware Technical enablement WebEx on AP they will be doing away with the * ability in the next release of AP as it allows for MITM attacks.

        Reply

  47. Thank for this Carl!
    How would you integrate this with Identity manager (a F5/NS LB pair)? Would the View URL point to the identity manager (Identity.corp.local) instead of “view.corp.local” ?

    Reply

    1. I don’t think Identity Manager is supported through Access Point yet. In Identity Manager, you’d point the Network Range View URL to the Access Point URL. I expect a future version of Access Point to merge both products.

      Reply

  48. Oh – One further thing! May or may-not be a bug, but after OVF deployment through the conventional vSphere 5.1 Client I was unable to communicate to the appliance. (The IP-Pools were configured beforehand with Subnet and Default Gateway)

    The only way I got it to work was by deleting the IP Pool and deploying the OVF from the Web Client only, which creates the IP pool for you. (I compared the one created by the Web Client and it was the same as the one i created) the deployment success just depended on the Web Client to roll out.

    May not be an issue on 5.5 or 6.0 but that’s what i seen on 5.1

    Reply

  49. Thanks for this Carl, I used both your blog and the Powershell application to configure the appliance. Quite complicated but got their in the end. Awesome that the Access Point no longer need JMS so it can be in a different datacenter than the View Connection Servers.

    You don’t know of a script to do the Certificate piece at all?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *