HAproxy loadbalancer and View 6.1.1

[SandervdB]

Hi All,

I'm running 2 Vmware View connection servers and 2 HAproxy's (version 1.5.15)  as loadbalancer in high availability.

Are there any members on this community know how i can redirect HTTPS correct thru HAproxy ?

When I use the balance option : balance source

No problems what so ever, but then the load isn't shared like round robin.

But when i choose as balance option: round robin

we notice error upon connecting to the connection servers: Your session has expired. Please re-connect the server.

This is due to session sticky i can't get to work.

All I want is to redirect the traffic TCP based (straight redirection) and the connections evenly directed based like round robin.

The config for HTTPS in HAproxy is:

listen https ***SOME VIRTUAL IP***:443

        mode tcp

        option tcplog

        option ssl-hello-chk

        balance roundrobin stick store-request src

        stick-table type ip size 200k expire 30m

        option srvtcpka

        server SERVERNAME1 IP1:443 check

        server SERVERNAME2 IP2:443 check

Cant find any solution regarding HAproxy and round robin. Anyone succeeded this ?

Also posted this on HAproxy forums but was wondering had this working correct.

Thank you in advance,

Sander

[DavidTWynn]

Have you figured this out?

[LarryBlanco2]

Here is a great guide for configuring and deploying HA Proxy with horizon:

http://pdfs.loadbalancer.org/Vmware_Horizon_Deployment_Guide.pdf

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!

LB

[DavidTWynn]

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!

[DavidTWynn]

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.

[LarryBlanco2]

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.

LB 

[DavidTWynn]

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.

[DavidTWynn]

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?

[LarryBlanco2]

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,

[LarryBlanco2]

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. 

[BenFB]

Just be aware of the Interoperability matrix for the Unified Access Gateways (UAG). In the original posters case a UAG is not compatible with View 6.1.1.

VMware Product Interoperability Matrices

[BenFB]

DavidTWynn​

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.

[DavidTWynn]

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.

[DavidTWynn]

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?

[BenFB]

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?

[DavidTWynn]

Ok I see. I have taken two UAGs and I have them in HA Fault tolerant mode so if one ESXi goes down I will be ok. And then when I need to take them down for updates I will turn on quiesce mode. Any chance you can send me that powershell script you are using to update your UAGs?

[LarryBlanco2]

never saw this... But the PS scripts are easily obtained from VMWare.. 

Using PowerShell to Deploy the Unified Access Gateway Appliance