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.