I have been deploying a VDI solution recently based on the fantastic VMWare Horizon Suite ↗, one of the important points of deploying the Horizon View ↗ component of this is making it highly available and accessible from the outside for on-the-road users.

The best way I have found to load-balance incoming connections (both internally and externally) is to set up a linux VM and run NginX ↗, which is a reverse caching proxy - it allows us to terminate the SSL connections and load-balance across our backend View Security Servers in a DMZ.

You could buy a hardware or VM load balancer from F5, Citrix, Barracuda but that will run into the £1,000’s if not £10,000’s. For our case, using NginX is more than adequate - please note some people use HAProxy, I don’t recommend this as it does not have native SSL (so HTTPS) support until v1.5 which is yet to be released.

Why is this important? It means you can use one address e.g: to act as a proxy for all the backend security and/or connection servers for your users, one address is simpler to use and remember, for you, it streamlines configuration.



So to get down to it, here’s a rough topology of what your config would look like:

VMWare View NginX LB

Ubuntu Server

I assume you have your linux VM installed (say Ubuntu), static IP assigned and DNS setup point to this address.

Firstly we need to install NginX:

aptitude update && aptitude install nginx

SSL Certs

Next as VMWare View’s servers require SSL we need to have an SSL cert signed by your CA for this VM for the address

mkdir /ssl && cd /ssl
openssl genrsa -out 2048
openssl req -new -key -out

Have your CA (whether AD internal or external CA) sign the cert, retrieve the request by doing this:

cat /ssl/

The output is your Certificate Signing Request.

If you are using an internal Microsoft CA you can have it signed by the web GUI:

  • Go to: https://[]/CertSrv/default.asp
  • Click “Download a CA Certificate, Certificate Chain, or CRL”
  • Click “Base64 encoded”
  • Click “Download CA Certificate”
  • Go back to: https://[]/CertSrv/default.asp
  • Click “Request a certificate”
  • Click “advanced certificate request”
  • Paste in request and change template to web server
  • Click “Submit”
  • Download certificate (Base64 encoded) not the chain

Open both files with a text editor like Sublime Text 3 ↗ and order them in a new file like so:

Server Certificate
CA Root Certificate

Save it as a new file and transfer it to the /ssl folder on your NginX server.

NginX Config

Edit the /etc/nginx/nginx.conf file and add the following to the http { section: remember to change the upstream addresses to match your View Security Servers addresses!

# enable reverse proxy
proxy_redirect              off;
proxy_set_header            Host            $http_host;
proxy_set_header            X-Real-IP       $remote_addr;
proxy_set_header            X-Forwared-For  $proxy_add_x_forwarded_for;
client_max_body_size        10m;
client_body_buffer_size     128k;
client_header_buffer_size   64k;
proxy_connect_timeout       90;
proxy_send_timeout          90;
proxy_read_timeout          90;
proxy_buffer_size           16k;
proxy_buffers               32  16k;
proxy_busy_buffers_size     64k;

upstream hrz-view-cluster {
    server fail_timeout=1s max_fails=1;
    server backup;

You can of course add more upstream servers by simply adding them to the upstream section - you will also notice we are running in active-backup, this is important to preserve sessions otherwise logins don’t work as the requests get split across the two servers.

You can use the ip_hash module ↗ to encourage session persistence and split the load evenly (more like proper active load balancing than the failover scenario above) - however this module has a few drawbacks listed in an article here ↗:

Collisions as it only uses the 3 first numbers of the IP for the hash. That means that all the ips of the same C-class network range will go to the same backend server.

All users behind a NAT will access to the same backend server.

If you add new backends, all the hashes will change and sessions will be lost.

Please note: ip_hash does now support IPv6.

upstream hrz-view-cluster {

The final thing we need to do is set up our NginX server block for the “site” by editing /etc/nginx/sites-enabled/default, empty its contents and add the following: (Change the instances to your own address)

#redirect all http to https
server {
        listen 80 default;
        rewrite ^ permanent;

server {
    listen 443 ssl;
    ssl on;
    ssl_certificate /ssl/;
    ssl_certificate_key /ssl/;

    location / {
        proxy_pass https://hrz-view-cluster;

Save file, and restart NginX:

service nginx restart


Test your http redirect by going to in your browser, you should be redirected to: and see something similar to this:

NginX proxy for VMware Horizon View

And you’re done! You can now use this address in your VMWare View Client to connect to your remote desktops:

VMware Horizon View login screen

Why not follow @mylesagray on Twitter ↗ for more like this!