Have you figured this out?
Here is a great guide for configuring and deploying HA Proxy with horizon:
Their appliance is HA Proxy underneath, they have a nice gui and HA proxy is all configuration files, but overall it gives you what you need. Also note that HA Proxy DOES NOT loadbalance UDP only TCP. I say this because PCoIP and BEAT can and do use UDP which can cause the issue mentioned above.
Your LB method will need to be one that accounts for this. In our case we chose "External Clients - Option 2" on page 9 of the PDF as our configuration for both external connections (UAG) and internal connections (CS).
it load balances the connection well and we now have redundancy and high availability.
Hope that helps!
Thanks for the reply man! Ok I just went through the document and it seems great. I see that I will need to layer 7 HTTPS and then make VMware Blast on TCP/UDP 8443 go directly to my connection server without hitting the load balancer. I have a question though. How do I split the HTTPS data to go to the load balancer and then Blast protocol directly to the connect server? I am guessing that it is this right, by editting the connection server settings? I will try this when I get back from lunch and see what happens! THANK YOU!
What do you have set for your secure tunnel and your blast gateway on your connection servers? vdi2.example.com:443 is my loadbalancer and intconnect1.example.com:8443 resolves to the connection server. The issue is that I get an error stating Could not establish tunnel connection from the Horizon Client. I can only connect with the client to the loadbalancer if both the HTTPS Secure tunnel and the blast secure gateway are set to the intconnect1.example.com address.
You no longer need to have those boxes check when using UAG's. So my two connection servers do not require anything in there any more Everything is unchecked. From what I understand, the clients already encrypt the initial brokering and then the connection to the desktops. Added benefit, if you need to restart a connection server it would no longer drop all your sessions as they are now directed to the actual VM's. This was our biggest moment of enlightenment. No longer requiring the secure tunnels and the security gateways. Now we can upgrade the infrastructure till our hearts content without causing users any downtime.
In my configuration I have 4 ha proxy load balancers. 2 in the DMZ and 2 inside the LAN
The UAG servers are configure with a 2NIC config. One nic on the DMZ and the other inside the LAN.
So my public DNS has 3 records (3 IP addreses). One being the LB-VIP (vdi.xxxx.com) and the other 2 are for the UAG servers (UAG1xxx.xxxx.com and UAG2xxx.xxx.com)
the UAG servers are configured like this:
The Connection server URL is the VIP for the HA Proxy servers on the inside (LAN). Which then load balances the connection servers for brokering.
The PCoIP Ext. URL is the actual outside IP address of the individual UAG server. it has it's own IP address. The other server is x.x.x.x4
The Blast Ext. URL is the DNS name of the IP address of the individual UAG server (Same IP as the PCoIP). The other server is uag2xxx.XXXXX.com
I just needed to make sure the firewall was allowing thru all the needed ports from the 3 external ip addresses (LB-VIP, UAG1, UAG2).
I think the above makes sense, well at least I hope it does. It was a bit of trail and error getting it all running.
Amazing post man ! Thanks so much for your reply! I should have said that I am working on HAProxy for my internal clients first before working on my external connections. I will definitely use your setup for when I work on load balancing external connections.
So when your internal clients connect do they go to the virtual ip of your internal load balacers?
And does not configuring the secure gateways of the connection servers mean that Blast and PCoIP traffic get set directly to the View agent on the VM, instead of going to the connection server and then the VM?
So 443 traffic from an external client gets sent to an external IP of your company that gets natted to your virtual IP for your DMZ HAProxy Servers. Then 443 from the HAproxy server gets pushed to a UAG and the UAG says to connect with Blast use 8443 of my external DNS ip. Then the client goes to a different external IP of your company with 8443 and gets natted to the UAG server that the HAProxy server load balaced to. Then UAG sends 443 to the internal virtual IP, and the 8443 to the View Agent on the VM. Ok I think I got it.
Thanks again, this is quite the setup.
Wow man no way!!!!! ITS WORKING NOW! Thanks a ton. It was the secure gateway settings. I should have know what they did but I thought that load balancing would work with it. I tried taking down both connection servers one at a time and the session was always up. This is dope! Now on to the external access. I already have security servers up in place, should I take the time to install UAGs or should I just use security servers?
And do I need to have two nics on them? Why didn't you just open some back-end firewall rules from your DMZ IP of your UAG to the internal network?
Yes.. All the internal client connect to the internal VIP of the LB. granted the connection servers themselves have their own DNS name and are accessible directly from the client but the users are unaware of it. All they know is vdi.xxxxx.com
The clients do authenticate against the connection server. So if they have multiple pools or apps they are entitled too it all shows up on the client side (the brokering part). Once the user selects a desktop or app, the client will establish a direct connection to the agent therefore no longer needing the broker.
As for your last paragraph. yes, that seems pretty much it in a nutshell,
I would go with UAGs as they will eventually do away with the security servers. Plus, using the PS script to set them up and upgrade them is as easy as it can get. Upgrading them consists of powering one of them off, deleing the VM, and then running their PS script to bring up the newer one with your config. I'll eventually add to that PS script where it will automatically do that entire process for me in one fell swoop.
In our environment our networking team decide to only have a front end firewall. I don't know why they wouldn't have a traditional front end and backend firewalls for the DMZ like the rest of the world has, but I have other battles to fight before getting back to this one.
The tunnels must be disabled on the connection server since the UAG is now acting as the tunnel (Connections through a UAG will fail if the tunnel is enabled on the connection servers). The UAG will tunnel all communication from the Horizon Client to the Horizon Agent like the connection server/security server previously did. When you disable the tunnel on the connection server and point the internal clients to those connection servers they will still talk to the connection server to complete the horizon primary protocol (authentication/pool selection) but for the horizon secondary protocol (Blast/PCoIP/RDP) the internal client will talk directly to the horizon agent.
I'm doing a nearly identical deployment as LarryBlanco2 but we use F5 load balancer instead.
1 public IP/DNS for the VIP on the load balancer to complete the horizon primary protocol.
1 public IP/DNS record for each of the UAG NAT to the external NIC of the UAG for the horizon secondary protocol. The UAG has the DNS record configured in the blast external URL field so the horizon secondary protocol is not flowing through the load balancer.
Thanks man I appreciate it! That interoperability matrix is really gonna save me some trouble. Now that I have internal load balancing working I will move on to external. I will get some UAGs up this week and get them tested. Thanks again.
Ok so internal loadbalancing is great and when I take down one of the connection servers the connection stays up. I have 2 Centos HAproxy loadbalancers in dmz listening to 443 and 2 UAG servers with one nic in dmz. For UAG config I have the internal loadbalancer hostname for the connection server url, and their external hostname for vmware blast set to default 8443.
The issue is with external access failover. When I turn off a connection server the blast session stays up. But when I take down a UAG the blast session ends and I have to disconnect and reconnect for it to work. I have enable udp tunnel server and enable tunnel set to no.
Any idea how I can get 8443 to fail over to the other UAG? Could this be because I am only using one nic?
This is the expected behavior. The session is authenticated and tunneled through a specific UAG and can not be failed over to a different UAG.
markbenson Any chance we could see clustered UAG that synchronize the session states to allow for this type of maintenance/fail over?