Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

VMware View Black Externally

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.

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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?

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Yep, we're at 5.2

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Can you verify your server ssl profile has the following in the server name field:pcoip-default-sni

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Yes it does, just like the internal VIP.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
Comments on this Answer
Comment made 24-Jan-2014 by Martin Vlasko 300
hi Travis, did you find a solution to your issue with the black screen? I am trying to set up exactly the same environment, but I am stuck also with the black screen and I already lost all clues..
0
Comment made 24-Jan-2014 by travis99 199
Yeah, I missed the "optional" instructions if you're external IP is behind a NAT. Page 58 of the guide. I'm also waiting for my own test connection server so I can do everything the guide asks to do on the CS. (Optional: If using a translation device between the View Clients and the BIG-IP system) Click the + symbol between AD Auth and Advanced Resource Assign.
0
Comment made 24-Jan-2014 by Martin Vlasko 300
I have tried that as well, but no luck. Now I moved my test client on an external network that can reach external F5 VIP directly, without NAT, so that the "optional" feature is not required, but it still does not work. After successful authentication I am able to choose from the virtual desktops.. when I choose one, the VM window opens, but with the black screen. In exactly the same time when the VM window opens, I can see packets on each side of the F5. The number of packets is the same on each side, so I assume they are related. on the external side, from the client to F5 VIP it is TCP/443 traffic, on the internal side, between F5 internal self IP (VIP) and the chosen virtual desktop it is TCP/4172 traffic. But there is absolutely no UDP traffic anywhere..
0
Comment made 07-Sep-2014 by Thomas Schockaert 188
I'm having the EXACT same problem as what Martin Vlasko has described: no UDP:4172 anywhere to be found. I'm seeing a PCOIP Hello message in the data being sent to the :443 virtual server. I'm also in full proxy mode, with an APM setup. I still need to take a pcap on the client to see if it is actually sending any UDP:4172, but I can't find it anywhere on the F5. I sniffed using rdsh 0 with tcpdump -nni 0.0:nnn => nothing I sniffed on the F5-internal proxy interface it creates when activating the VDI & Java support checkbox => nothing I sniffed on the actual VLANs using rdsh 0 with tcpdump -nni /Partition/VLAN => nothing Anyone got any ideas?
0
Comment made 15-Sep-2014 by Thomas Schockaert 188
This got fixed by installing the latest hotfix to v11.4.1 (HF4) - So there was an issue - not sure if it's a known bug, but it probably is.
0
Comment made 15-Sep-2014 by Thomas Schockaert 188
I am now having a problem with USB redirection with the native PCoIP proxy. Apparently it simply does not work. Did anybody get this working, or an ETA on the version in which it is officially supported? It seems silly to create a native PCoIP proxy without including USB redirection (which actually makes the whole thing usable for actual users).
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

yes

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

You need to modify external default gateway to match your LAN gateway.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Also, do you translate your Public IP?

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

Jim

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Greg

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?

Jim

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Horizon client sends first UDP

0
Comments on this Answer
Comment made 27-Jul-2015 by Greg Crosby
does tcp4172 connection become established between apm and horizon agent (published resource) or is it being reset?
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

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

Jim

0