This is my first post and I am not an F5 guru but I am wondering if anyone has gotten all the ports working for VMware Horizon View and the latest iApp for Horizon View. I am specifically wondering if anyone has gotten HTML5 to the desktop working in their environment. We have 4 brokers all running View 5.2. Accessing the individual servers works fine using HTML5. When trying to add 8443 it appears like it will work but it looks like it failing on the connection to the Broker after Authentication. From a Network trace it appears we connect on 443 (authentication) to one broker and then when we try to connect to 8443 (HTML 5 access to the desktop) it fails. If I disable 3 of the 4 pool members it works every time. If I enable 2 of the 4 pool members if fails 50% of the time....
If you are using 11.4 HF3 or 11.4.1 then you can follow the section listed as "Presenting a View Desktop on an APM Webtop" in this
vmware intergration guide
If you are using the iApp listed here with APM and the option to use Secure PCoIP proxy, then you can add client type detection which will let you branch based on client type. You can use the iApp created branch for the "VMWare View" client type branch (view clients) and create a separate branch for Browsers. The policy will look similar to this:
The second branch will enable HTML 5 browsers the option to choose HTML 5 when connecting to HTML 5 enabled pools:
Hi Chad, what version of software are you running on your Big IP and what scenario are you using with the iApp? IE - are you using APM with pcoip proxy? Also, what View iApp template are you using?
You should be able to use the native HTML 5 functionality, did you add persistence to your 8443 virtual server?
Using 11.3 and the iAPP without APM, it did not create the HTML5 8443 ports as I would have expected if the iAPP was going to support the View 5.2 features. So are you saying to add an additional 8443 (VIP?) to the iAPP?
The iApp currently does not support a HTML 5 configuration, so you will need to add a VS using port 8443. You also need to configure your View servers to use the same IP address you used when creating the 8443 VS on your BIGIP. The setting is labeled as "Blast Secure Gateway" configuration option found in the View administration console.
Greg - Thanks for the info. Would I then turn on persistence on the VIP for 8443? The issue we had in testing when adding this was the authentication occurred via 443 on one broker and then when connecting back via 8443 it went to another view broker.
Yes, select "Match across services" in your persistence profile so the client always goes to the same node across the various service ports. I am assuming you are using the same IP address and same pool members for your 8443 and 443 view vs.
Greg, Yes you are correct in your assumptions. Thank you everyone for this helpful information. I will let you know how it goes next week. THANKS AGAIN!
Chad and Greg what is the verdict on your configuration? I am trying to load balance HTML5 as well but on View 5.3. I am also on BIG IP 11.2 HF7 without APM. I am using the latest iapp as well. I have 2 security servers paired with 2 connection brokers for external connections and VMware has already confirmed that everything is configured correctly without going through the load balancers.
The iApp is not setup to support HTML 5 clients. So you need to: create another VS using the same ip as your iApp created 443 vs on your BIG-IP using port 8443, use same pool as your 443 virtual server, modify persistence profile applied to vs 443 to use "Match Across services" option, and verify "Blast External URL" matches "External URL" within your View administration console for both connection and security servers.
Have you successfully connected to a virtual desktop using a html 5 client (without ltm)? If not, verify Horizon View html access has been installed on all your view connection servers, your virtual desktops have both view agent and remote experience agent installed, and verify HTML access is enabled within your pool you are trying to connect.
I have successfully connected to a virtual desktop using html 5 without the LTM. I did change the Blast External URL to match the External URL as well as made sure the same pool was used for 443 and 8443. I am still having an issue with website not found or network connection was lost after authentication and selecting the virtual desktop for connection.
I am in the same situation to Evon and I am wondering if this has ever been resolved?
We currently have Horizon View 5.3 and everything works for HTML5/Blast going directly to our security server before we introduce the F5 Big IP LTM.
When we login and select the desktop pool where the BLAST 8443 redirection takes place, we receive a 404 Error page not found message.
I have created a separate VS on the same VIP for 8443 and given it the same settings as the 443 server (http profile, persistence, pool member). I am unable to find any documentation anywhere on how to get it to work!
I've managed to solve the above problem as I stated above.
I created a new pool for the security servers using 8443. Previously it was set to use the same pool as our 443 nodes. (All nodes the same, just different port).
It seems obvious now I guess!
I'm trying to get the HTML5/BLAST config working with version 1.1.0 of the iApp. for the people that have this working did you get it working with just the APM or did you use all use a VMware view security server as well?
When I log on to the APM my webtop displays a message saying that "Logon to VMware server failed" (I know my username and password are correct as the APM authenticated me before the webtop) I can't see to find anything in the logs.
If I use my full view client through the iApp it does work or though it does ask my to authenticate twice.
Any thoughts, advice would be appreciated.
I too am trying to get the HTML5 Blast to work. I am running BIG IP 11.5.1 and View iAPP version 1.1.0. It says in the release notes that this iAPP supports the HTML5 blast, but it does not create a pool for the 8443 ports. I was able to confirm this works when bypassing the F5 LTMs. I have an open case with F5 support and will let you know what I find.
Port 8443 is not always used with HTML 5 clients. The iApp offers several ways to configure your BIG-IP based on your available BIG-IP modules and your specific View configuration.
The only configuration produced by the iApp that supports HTML 5 (without modification), is the scenario were you use APM to "Securely proxy PCoIP traffic using APM as a PCoIP gateway". It is the default iApp option when using APM with software versions 11.4-11.5.1 (11.4 is required to support PCoIP proxyied connections). The question directly after in the iApp is whether or not you want to support HTML 5 client connections, select yes for this option.
Using these options in the iApp, once you connect to the big-ip using a supported browser, you will see the option to use html 5 clients when selecting virtual desktop pool (don't forget you have to have the "HTML Access" option enabled on the pools settings).
For those wanting to configure LTM only, or do not currently have the APM module, you have a couple modifications to make after running the iApp. Here is a brief description of the required changes after running the iApp:
If you are using security servers, create a virtual server using port 8443 and attach the security server pool created by the iApp to the virtual server. You will also need to modify the persistence profile created by the iApp to "match across services". For this setup the connection server will need to have "Blast Secure Gateway" enabled and set to the correct fqdn:port. Once the clients have successfully logged into the security server, they will attempt to make a 8443 connection to the same security server which proxys 443 connections to the correct virtual desktop.
If you are not using security servers, create a forwarding (ip) virtual server using the network your virtual desktops reside for the destination network, and port 443. Once clients have successfully logged into the View connection server, they will attempt to make a 443 connection directly to the assigned desktop. For this setup, you will need to have "Blast Secure Gateway" disabled on each connection server.
aschaef, let me know what configuration you are trying to use and I can assist further.
Greg, thanks for the reply. I currently have 2 pairs of F5s, 1 sitting in the DMZ which is licensed for LTM/APM and another virtual pair of F5s licensed for LTM only. On the view side I have 2 security servers and 2 connection servers. I have been trying to figure out the best way to provide both internal and external connectivity for clients. Currently I have the internal LTMs setup and working to load balance PCoIP clients directly to the connection servers. I was reading some F5 deployment guides and it was showing that with the APM piece they had an optimized design which provided a PCoIP directly to the connection servers as well. At this point the security servers aren't doing anything. I would like to provide HTML5 access at least to external clients, so I may not set it up on the internal LTM side. We are using split DNS so I have all clients pointed to view.domain.com regardless if they are internal or external. Internal DNS will resolve to the LTM virtual IP and the external DNS will resolve to the public IP setup for view on the APM F5s.
There is a straight forward (meaning very few options) iApp on devcentral that supports the optimized solution you mentioned. The iApp assumes a single BIG-IP deployment were APM has access to your untrusted (public) network and trusted View networks. APM's trusted connection needs to be able to communicate to your View Connection servers (tcp 443) and to your virtual desktops (tcp 443 & udp 4172). The iApp creates 5 virtual servers; 2 for internal trusted client connections, and 3 for untrusted client connections.
Summary of iApp virtual server creation:
Untrusted ip1:tcp:443 vs - lb auth requests to connection servers and manages html 5 connections to virtual desktops.
Untrusted ip1:udp:4172 vs - manages pcoip connections to desktops
Untrusted ip1:tcp:80 vs - redirects 80 connections to 443
note: apm inserts untrusted vs ip1 into sta ticket on the way back to the client which forces all client desktop connections to APM. APM handles AD authentication and securely proxy's pcoip/html 5 connections, thus replacing the security servers role. Using your split dns, you would point all external/untrusted networks to this address.
trusted ip2:tcp:443 vs - lb auth requests to connection servers
trusted ip2:tcp:80 vs - redirects 80 to 443
Note trusted clients need to have access to virtual desktops via tcp 443 (html 5 client connections), and tcp/udp 4172 (pcoip connections) since apm is not managing/proxying trusted connections to the desktops. Using your split dns, you would point all trusted networks to this ip address.
Sorry for the long narration, I just thought i would give you a little context before jumping into using the optimized solution iapp on DC. There is also a DG noted in the link that you can read through for more through details.
Thanks for the overview, that actually helped me wrap my head around everything. I am going to remove the configuration on the internal LTM pair and just use the pair of F5s in the DMZ with APM. Do you know if there is much of a difference between the View 1.1.0 iApp and the Optimized 1.1.0rc1 iApp? I may try the original one first since I'm not using the virtual edition of BIG-IP on the pair which has APM.
I had much better luck with the optimized iApp. Everything is working so far on the PCoIP side, but not quite like I'd expect on the HTML5 side. For example if I was using desktop.domain.com with split DNS and I open a web browser from an internal client and go to https://desktop.domain.com I am presented with the VMware View page where I can choose to install a view client or use HTML access. If I select HTML access I am presented with the login page and am able to successfully authenticate and see my View desktop. When I connect to the desktop, I am redirected to a URL which is actually the IP address of the desktop and receive an SSL certificate error. The connection works, but I would expect the url to remain desktop.domain.com so the SSL cert would be valid.
I tried going back to the connection server settings and checking the boxes next to "Use Secure Tunnel connection to desktop" and "Use Blast Secure Gateway for HTML access to desktop" and the URL remains desktop.domain.com but I get a page could not be found error. As it stands now, the only box which is checked under the view connection server settings is the Use PCoIP Secure Gateway for PCoIP connections to desktop with the IP address pointing back to the trusted F5 virtual server address.
I currently have all boxes unchecked on both view connection servers.
I am trying the following tests to make sure the view machines are reachable both internally and externally with PCoIP and HTML5.
Internal PCoIP test using View Client - works great
Internal HTML5 test using https://desktop.domain.com successfully authenticates and then brings me to the following URL where I get a security certificate warning "https://10.0.0.10:22443/d/499849BA-A092-44AB-8D7E-330903764E73/?vauth=tbQ5v%2FXNaAyQnXL0FRZbCJ%2BL" If I accept to continue then the desktop loads (my only issue is the certificate warning)
External PCoIP test using iPhone - works great
External HTML5 test using iPhone - works with Chrome, but not Safari browser
External PCoIP test using domain laptop (not on VPN) - Successfully authenticate using the View Client but it sits and spins on "The Connection Server is preparing the desktop..." I then tried going to https://desktop.domain.com and choosing VMware View Client. The behavior is the same where the client sits and says "The connection server is preparing the desktop..."
External HTML5 test using domain laptop (not on VPN) - works great.
I may have to just ignore the internal HTML issue. If I replace the certificates, they would be using the VMs hostname, the HTML blast redirects me to the IP address of the VM so it would show a certificate error regardless. I'm most likely not going to have internal users using HTML very often, but I was trying to provide it as an option. Thanks again for your assistance.
Any chance that the View iApp template will be updated to support HTML5 clients when NOT using the APM? Would be nice to have it created the additional virtual server on 8443 and modify the persistence profile for match across services without having to turn off strict updates for the application configuration.