Just curious if anyone has run into a black screen using View on external VIP? On our internal VIP it works great. Running 11.4.1, latest iApp, 4172 is open inbound to the external VIP. This is launching from the webtop link that is created with the iApp. It opens the View client, logs me in, starts the session, then a black screen.
As you probably know, a black screen indicates a PCoIP problem. Couple of questions for you: Are you using and iApp to configure your external VIP, and if so what version? Can you verify the external connection has a route to your VDI? Are you using PCoIP Proxy or are you just forwarding the PCoIP traffic onto your VDI?
Yes on iApp - 1.0.0rc5. We have a two leg F5, one in DMZ and one on internal network, the current route is set to use the internal gateway. I set it up with PCoIP proxy.
What version of View are you using? PCoIP proxy with BIG-IP requires server and clients to be at a minimum version of 5.2.
Yep, we're at 5.2
Can you verify your server ssl profile has the following in the server name field:pcoip-default-sni
Yes it does, just like the internal VIP.
Try running a TCPdump on the BIG-IP for UDP:4172 to verify the traffic is making to the BIG-IP and being sent to a virtual desktop address.
I may have discovered a little irk externally. It starts the connection, then it attempts to connect again throwing off the initial connection and fails. So I'm attempting to track down where it's doing this in APM. TCP dump on internal connection was good, 4172 traffic flowing on designated VIP.
You need to modify external default gateway to match your LAN gateway.
Also, do you translate your Public IP?
I am having the black screen issue to. Using LTM, APM, iApp f5.vmware_view_optimized_solution.v1.2.1. Doing a TCPDump I dont see the F5 generating any UDP 4172 packets.
View client sends messaging to setup PCoIP UDP display protocol between Horizon Client and assigned resource. This traffic flow occurs from Horizon Client to APM over ssl and proxied from APM to assigned resource over TCP 4172. You should see communication over tcp 4172 from APM to the assigned resource prior to seeing any UDP 4172 traffic. If not, I would check the port is open between APM and the Virtual Desktop / Virtual App networks. Once initial setup occurs you should begin to see UDP 4172 traffic from client to apm and from apm to the assigned resource.
I would also verify the connection servers are not setup to use https/pcoip as APM handles directing clients to the correct ip addresses. Another thought is to run a capture on the client to see if it is sending UDP packets anywhere other then the correct APM IP address.
In the capture i see TCP 4172 packets but no UDP 4172 packets. The connection servers have all three check boxes cleared. Question, who sends the first UDP4172 packet?
Horizon client sends first UDP
Greg, thanks explaining the communication for this application. It lead us to look at the firewall for UDP4172 from the client.. which was being blocked..
Everything works great now. Much appreciated