Setting Up VMware View with an F5 Load Balancer: The Reality Is…

One of my friends loves to tell me how things really are, in his opinion, by preempting the soon-to-be-delivered evidence with the phrase, “The reality is…”. That’s when I know I’m either wrong, or he just likes his opinion more. Either way, there’s two realities: I’m usually right and his information is wrong.

In this case, we have documentation from F5 and VMware on how to make these two technologies co-exist in a VDI infrastructure. We followed the documentation and, uh, the reality is…

—————————

Documentation referenced: Setting up View 5.3 with iApp f5.vmware_view.v1.0.0rc6
Objective- Setup Horizon View external connections through the F5 and test USB-Redirection with the following environment:

■Horizon View 5.3

■F5 LTM (Local Traffic Manager) v.11.2.1

■View iApp f5.vmware_view.v1.0.0rc6 (admittedly this version doesn’t officially support View 5.3, but since VMware’s own links to 5.3 refer to the 5.2 documentation, it seems a safe bet that it should work)

■2 internal only View Connection Servers on internal network

■2 external only View Connection Servers on internal network

■2 View Security Servers in DMZ connected to the external only View Connection Servers

■Wildcard SSL certificates on all View and F5 Virtual Servers

The security servers work flawlessly when connecting to them directly (assuming correct View settings) from an external client.

Setting up the internal connection servers using the iApp was successful. The problem has been the DMZ Security Servers connecting to the external View Connection Servers. Despite some forum comments that the iApp will work to setup a Security Server/Connection Server environment, the documentation has misleading (if not incorrect), information in setup and configuration design.

Documentation (deployment guide for this iApp version)
While it does show on page 5 that LTM supports using Security Servers, the traffic flow and description is misleading, since all traffic from outside the firewall is directed through the Security Server and never around it. There is no option to select a Security Server setup in the iApp itself, and when using it to create the service, it simply doesn’t work.

This is backed up by the document’s own manual configuration definitions (which are not 100% accurate either) on page 59, which is nothing like what is created when using the iApp. The configuration guidance for using Security Servers states that it requires 3 virtual servers; this does not seem to be true as USB Redirection is encapsulated in SSL from the external client to the Security Server and does not require a separate Virtual Server.

Another problem is the Security Server does not keep port 32111 open, so the health monitor used to verify the port’s availability can’t work correctly. Additionally, VMware’s own documentation for required firewall ports states that source port 32111 from the Security Servers should be open to destination port 4172 on the View desktop. In testing this rule did not work, only changing it to “source: any, destination: 32111” resolved USB-R (USB-Redirection) functionality. Also, nowhere in VMware’s documentation lists a requirement for port 32111 to be open to the security server from the View client. One other note, on page 60 in the guide, the first Virtual Server (TCP) for the Default Pool setting says: “Select the pool you created above”. It should be specific about which pool. It’s the UDP pool since it’s using port 4172, but that should be named something more generic since it’s for both the UDP and TCP Virtual Server.

Note: To complete the configuration you will also want to add a HTTPS redirect Virtual Server for the Security Server VIP and a Virtual Server for BLAST.

USB Redirection through the F5

It seems there are two viable options to setup Load Balancing (LB) with the Security Servers:
1. LB both HTTPS and PCoIP traffic
2. LB only HTTPS
USB-R Scenario Testing Results:

LB both HTTPS and PCoIP – in this option the Security Servers are setup with the following View options: HTTPS Secure Tunnel= URL that corresponds to the internet facing IP with NAT to the F5 VIP
PCoIP Secure Gateway = Internet facing IP of the F5 VIP
Blast Secure Gateway = URL that corresponds to the external IP (same as HTTPS Secure Tunnel).
With this setup all client traffic is passed through the F5. When using this method, the USB-R functionality is available, however it is EXTREMELY SLOW.

LB only HTTPS – using this option, the Security Servers are setup with the following View options:
HTTPS Secure Tunnel = the URL that corresponds to the internet facing IP with NAT to the F5 VIP
PCoIP Secure Gateway = the Security Server’s external IP (with NAT on the firewall)
Blast Secure Gateway = the security server’s URL that corresponds to its external IP
With this setup the client contacts the F5 Virtual Server and gets assigned to a Security Server via LB algorithms. The Security Server responds with its own Secure Gateway settings and the sessions commence: one HTTPS session on the F5 and the remaining sessions directly to the Security Server. When using this method USB-R behaves as expected.

So, we could just be satisfied with sticking to option 2 (LB with HTTPS). However, it is unclear whether or not there is any advantage with having PCoIP routed through the F5. If there are some WAN profile enhancements available via LTM, taking adavantage of them and resolve the USB-R slowness. If not, then LB with HTTPS seems to be the only option.

Advertisements


Categories: IT Pros, VMware

Tags: , , , , , , , , , ,

3 replies

  1. Could you elaborate on “To complete the configuration you will also want to add … a Virtual Server for BLAST.”? I can’t seem to find the correct configuration for the BLAST virtual server on the F5, but BLAST works fine when we bypass the F5. Otherwise, my environment is pretty much identical to what you describe for your setup.

    • Hi Steve.
      In the F5 we created a server pool containing the two View Security Servers that would handle the BLAST connections. In the pool settings, the service port was specified as TCP 8443 for BLAST and the load balancing method set to Least Connections. Once the pool was done, we created a virtual server in the F5 with a separate internal IP and the service port set to the same TCP 8443. In the Resources section for the F5 virtual server we added the previously created BLAST server pool. In the border firewall policies, the external IP to internal IP NAT rule for port 8443 points to the F5’s virtual server’s internal IP. This configuration allows for auto failover if we have a security server go offline and load balancing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Brad Hedlund

stuff and nonsense

MyVirtuaLife.Net

Every cloud has a silver lining.

Live Virtually

A Storage and Virtualization Blog

Virtualization Team

VMware ESX/ESXi - ESX server - Virtualization - vCloud Director, tutorials, how-to, video

www.hypervizor.com/

Just another WordPress.com site

VirtualKenneth's Blog - hqVirtual | hire quality

Virtualization Blog focused on VMware Environments

Virtu-Al.Net

Virtually everything is POSHable

Gabes Virtual World

Your P.I. on virtualization

Yellow Bricks

by Duncan Epping

Wahl Network

Technical Solutions for Technical People

Joking's Blog

Phoenix-based IT guy with too much to say...

%d bloggers like this: