markbenson's Accepted Solutions

It's similar. UAG is effectively an authenticating reverse proxy, but specifically for Horizon protocols (including Blast/BEAT, PCoIP etc) and so is not just a generic Web Reverse Proxy. Hope this answers this question.

srietberg​ - Yes, this is normal and expected. UAG is doing brokering with CS2 in site 2, but with CPA, a user can have a desktop/app session in any POD. When the user authenticates via UAG it will always be with CS2 in site 2, but when they launch a desktop/app that may be in site 1 or maybe in site 2 depending on how you have set up CPA entitlements. The user's Blast or PCoIP session could be from client > UAG > site-2 desktop or client > UAG > site-1 desktop.

Chris_Nodak​ - If you've added the RADIUS config (under "Authentication Settings") on UAG you should be able to select that in the Horizon Settings (under "Edge Service Settings") in "Auth Methods". Set it to radius-auth & sp-auth instead of (securid-auth & sp-auth). It is the Horizon Edge Service Settings that determines what authentication will actually be used for Horizon clients.

BenFB - The Horizon Tunnel on UDP 443 is not related to Blast/BEAT. Blast/BEAT is a display protocol and uses TCP 8443 and optionally, also BEAT on UDP 8443. Some people use TCP 443 instead of TCP 8443 when they have a requirement that if everything is blocked other than TCP 443, things will still work. The Horizon Tunnel on UDP 443 is separate. It is not a display protocol but an alternative to the control/authentication protocol (XML-API) that normally runs on TCP 443. It is used in "poor mode clients" where the is no TCP at all. Everything is UDP. Those clients start with Horizon Tunnel (UDP 443) to perform authentication and get the list of entitled desktops, then they launch a BEAT session on UDP 8443. Refer to the Horizon ports diagram - Network Ports in VMware Horizon 7: VMware Horizon 7 version 7.2 - Note the communication between client and UAG. You'll see that Horizon Tunnel on UDP 443 is separate to Blast Extreme (TCP 8443/UDP 8443). The diagram uses default port numbers. The reason you won't see documentation in Horizon Connection Server or Security Server guides about Horizon Tunnel on UDP 443 is because they don't support it. It is only supported between Horizon Clients and UAG. Your original question was "Can BEAT run over a different port that UDP 8443?". The answer is yes, but don't change it to a UDP port already in use such as UDP 443 or UDP 4172 etc. Pick an unused port. Better still, leave it as the default of UDP 8443.

I can't discuss future features. The options today are: 1. Enable Blast Gateway on Connection Server and have all clients (native and HTML Access) connect Blast via the Connection Server. 2. Disable Blast Gateway on Connection Server and use trusted CA certificates on the desktops and RDS hosts in order to satisfy the SSL certificate trust for browser HTML Access. 3. Dedicate 1 or more Connection Servers for HTML Access (with Blast Gateway enabled) and get browser users to use just those Connection Servers.

In order to support the internal zero clients with just AD password authentication you can use dedicated Connection Servers just for internal users. You then have other Connection Servers dedicated for external users. These can be configured for optional SAML and for RADIUS authentication. This will then support external users via vIDM with RADIUS authentication from vIDM. This is with the "external" Connection Servers. External users just using Horizon client with RADIUS from "external" Connection Servers. Internal users via "internal" Connection servers with just AD password authentication. All Connection Servers are part of the same POD. It's just that some are configured for external use and some for internal. Mark

A common approach is to deploy VMware Unified Access Gateway (which was previously called Access Point). See What Is VMware Access Point for Secure Remote Access | VMware End-User Computing That post includes a comparison with VPN technology. If your comfortable with a Windows server in the DMZ you can also deploy Horizon Security Server.

Server core OS installations are not supported. Horizon Connection Server 7.1 requires "Server with Desktop Experience" versions of: Windows Server 2008 R2 Windows Server 2012 R2 Windows Server 2016 Mark

We are aware of an issue with PFX file handling introduced in UAG version 3.0. There are 3 possible workarounds for this: 1. Use PEM format files for the certs and private key. 2. Specify the long alias name shown in the UAG Admin UI error message by copying and pasting that value into the alias field. (This doesn't always resolve it). 3. Reconstruct the .pfx file (as you noted) with the following openssl commands: openssl pkcs12 -in original.pfx -out original.pem openssl pkcs12 -in original.pem -export -out fixed.pfx This applies to PowerShell deployments and updates via the UAG admin UI.

Hi BenFB​ Yes, you have it about right. The flow for the secondary protocols such as the display protocols must go through UAG in order to get the right protection to ensure that these protocols only get to the data center resources (virtual desktops and RDSH servers) when they are confirmed as being on behalf of an authenticated user. It is also important that they are routed to the same UAG appliance as was used for the user's authentication flow. Most people ensure this by configuring their load balancer for "source IP affinity". This way, the secondary protocols from a particular client device will be routed to the same UAG appliance each time. The secondary protocols don't have to go through the LB but they do need to go via UAG. It is often easiest for everything to go through the LB as long as affinity is correctly set up. This source IP affinity is method 1 of the 3 possible methods. Each affinity method is described in the UAG load balancing guide. It also has an explanation of the primary and secondary protocols used with Horizon - Load Balancing across VMware Unified Access Gateway Appliances (formerly known as Access Point)

Yes. Installing Security Server on the same network will work. Alternatively, you can just enable the three gateways on Connection Server so that you don't need to install Security Server. These are: 1. Enable the Secure Tunnel. 2. Enable the PCoIP Secure Gateway 3. Enable the Blast Secure Gateway This gives you the Security Server functionality but on Connection Server. This can be a good option in cases where there is no specific DMZ network. For more information on this, refer to http://pubs.vmware.com/horizon-71-view/topic/com.vmware.ICbase/PDF/view-71-administration.pdf - pages 33-35.

OK, so this is progressing. Yes, having "Use Blast Secure Gateway for Blast connections to this machine" ticked on Connection Server would certainly have been the cause of Blast connection failures. It must be unticked so that the Blast Secure Gateway (BSG) is used on UAG instead. Before configuring RADIUS on UAG, make sure everything else is configured correctly first via PowerShell. Initially comment out the authMethods line so that it defaults to pass-through to Connection Server. Each time you change the .ini file, redeploy with apdeploy.ps1. 1. Test a native Horizon Client using PCoIP. 2. Test a native Horizon Client using Blast. 3. Test the HTML Access Client (which also uses Blast). If any of these 3 tests fail, that will need to be fixed first. Once the above 3 work, then move on to RADIUS configuration. You can either have RADIUS configured on UAG or on Connection Server but not both. When it is configured on UAG it is important that any firewalls allow the UDP protol on port 1812 and replies so that this is not blocked. This is checked when the appliance is deployed and if this fails, RADIUS does not get set up. It sounds like there may be another issue with this config as well. If after you've worked through these things you are still stuck, you can  private message me and attach the logs .zip (which you can download from the admin GUI) and attach your .ini file and I should be able to determine what's wrong.

OK. So change the .ini file so that it instead reads: [General] # # UAG virtual appliance unique name (between 1 and 32 characters). # If name is not specified, the script will prompt for it. # name=ap1 (here ap1 is just an example of the name you want for your appliance). You can also download the latest .zip file apdeploy script and that allows you to leave out the name specification and it will prompt for it instead (i.e. if you delete the whole name=ap1 line). My advice though is to have it in the .ini file so that you don't have to enter it each time you run the script. Each time, you run apdeploy.ps1, it will replace any existing appliance of that same name. This is useful when you change settings or upgrade/downgrade the .ova image. The GetAPName issue you had was with the combination of using an older apdeploy.ps1 script (not the latest UAG 2.9 version) and not specifying the name=xxx line in the .ini file. Hopefully you are passed that issue now. Use the example .ini files to start with as they are all valid examples. You can then just change the values for your own environment.

There are 2 options here. UAG (AP) normally uses an internal DNS server to resolve names. You specify the DNS server with the "dns" keyword in the UAG PowerShell .ini file. SeeUsing PowerShell to Deploy VMware Unified Access Gateway (formerly known as Access Point)​.  You would expect UAG to resolve the names of your Connection Server hostnames to the 172 addresses. If UAG doesn't have access to DNS you can either add hosts file entries (also in the .ini file) or configure proxyDestinationUrl in the [Horizon] section to reference an IP address (e.g. 172.20.12.3 instead of vdi.mycomp.com). Either way, proxyDestinationUrl is used on UAG to establish a connection to Connection Server(s). The "split DNS" you've set up is good because internal users can connect to Connection Server(s) and external users can connect to UAG(s) with the same URL hostnames.

This support may be added in a future version - i.e. have the option to have it disguised, set to the real IP address of Access Point for any of the 3 NICs (depending on which one is used for the RADIUS communication) or to allow it to specified as any specific IP address. I was just answering the question for current shipping UAG 2.9 and previous AP versions. For selecting shared secret and replying to RADIUS requests, the source IP address in the UDP/IP packet is used. Mark

josefdi Thanks for the .ini file. It helps. Looks like the configuration is not quite correct. In the [Horizon] section, you have proxyDestinationUrl=https://connectionsvr1.domain.com I'm assuming connectionsvr1.domain.com can be resolved by Access Point and resolves to a Horizon Connection Server in the internal network. If so, that is correct. However, the external URLs specified below this are not correct. The first two reference the same connectionsvr1.domain.com, and that is likely to be the problem here. You have: #################################### # # The following external URLs are used by Horizon Clients to establish tunnel, HTML Access and PCoIP connections # to this Access Point appliance. If they reference a load balancer name or address then the load balancer must be # configured for source IP hash affinity otherwise the connections may route to the wrong Access Point appliance. # tunnelExternalUrl=https://connectionsvr1.domain.com:443 blastExternalUrl=https://connectionsvr1.domain.com:443 # # pcoipExternalUrl must contain an IPv4 address (not a DNS name) # pcoipExternalUrl=10.179.134.11:4172 #################################### External URLs are used by  Horizon clients, and connectionsvr1.domain.com that you have specified will probably not be able to be resolved by the client. e.g. with a Windows Horizon client you will probably see a message "Error: Unable to resolve server address. No such host known.". That happens because the client on the Internet is trying to establish a tunnel connection to connectionsvr1.domain.com and it needs to get to Access Point for this. If this is the case, change tunnelExternalUrl and blastExternalUrl to use a hostname that the client can use to connect to Access Point. This is usually the same hostname that the client initially specifies to connect. pcoipExternalUrl is similar except that it must use an IP address. This is normally the IP address that the other ExternalUrl hostnames resolve to. It is also used by the client to connect PCoIP to Access Point. There may be other config errors, but fix these 3 externalURL settings first and then just rerun apdeploy.ps1 command to redeploy. Retest first with a Horizon Client to make sure the Horizon settings have been corrected. If there is an error, let us know precisely what the error says, and at what stage it is shown.

It could be because "screen DMA" has not been enabled for the VM. Try enabling it. Refer to the note at the end of page 7 here - http://pubs.vmware.com/horizon-71-view/topic/com.vmware.ICbase/PDF/view-agent-71-direct-connection-plugin-administration… Also see Manually enabling screen DMA in a virtual machine (2144475) | VMware KB This is in addition to ensuring sufficient video RAM (e.g. 128 MB) for the VM. Let us know if this resolves it.

Yes. You can use just a single DNS name for both e.g. horizon-and-ws.domain.com. Read the note though on the slight nuance of this because it will then not allow access to the Horizon HTML Access directly. A user who would enter just horizon-and-ws.domain.com would get to Identity Manager and not the HTML Access page of Connection Server. There's a valid case for both options. It is the proxyPattern setting for each that determines the forwarding rules. Mark

Thanks for your detailed and accurate information. Yes, so your first problem is solved in that there was one or more invalid characters in the thumbprint value you pasted in to the admin GUI. I know the PowerShell method of deployment resolves that automatically so we should really get the admin UI to do the same. See Using PowerShell to Deploy VMware Access Point  - Anyway looks like that first issue is answered. The second issue (Certificate does not conform to algorithm contraints) is caused by the use of an incompatible signature algorithm for TLS. It is likely that TLS/Java doesn't support RSASSA-PSS as a signature algorithm. RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2​ states: Note that there are certificates that use algorithms and/or algorithm   combinations that cannot be currently used with TLS. For example, a   certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in   SubjectPublicKeyInfo) cannot be used because TLS defines no   corresponding signature algorithm. Is the certificate you show from the Connection Server or is it the certificate you have installed on Access Point (or both)? Is it possible for you to use an SSL server certificate with sha256RSA instead?