View 5 PCoIP Black Screen

[ClayPowell]

this is not the typical black screen displaying the connection ended.....

i have followed all related documents and setup guides but cannot get outside office PCoIP connectivity to our view environment working properly.

my setup...

SonicWall NSA 2400 firewall, ports 80, 443, and 4172 (tcp and udp) forwarded to security server, no outbound connections filtered.

security server, connection server, and ESX/vCenter serve running the view desktops all on internal LAN, no DMZ.

everything works internally fine, externally only RDP connections will work

PCoIP connections connect to security server, i authenticate, select my desktop/pool and get a black screen,... but the desktop never loads, i receive a connection timed out error.

i found many different issues relating to the black screen with the connection being ended, but nothing on the timed out error.  my public URL and public PCoIP URL on the security server is set to the public IP address we are trying to connect from externally and the name is resolvable by the external client.

any thoughts or suggestions would be greatly appreciated... thanks!

Also, local windows firewall is turned off on the servers, desktops, and the external client

[griffinboy]

In your Connection Server settings, have you ticked the 'PCoIP Gateway' box?

So, you have two interfaces on your SonicWall (one public and one private) and you do the NATing there? And your Security Server Gateway URL is set to be that external IP?

[ClayPowell]

yes i have that box checked and yes the Sonicwall is doing all of the NAT'ing and port forwarding/filtering.  actually using 3 interfaces, 2 public (one T1, one DSL) and one private on the LAN.  i have this particular connection setup to come in on the T1 interface and forward through to the security server

[markbenson]

I realise that I'm sounding like a broken record on this, but if it works internally, works externally with RDP and gives a black screen with PCoIP externally, then there is a 99% chance it is because of one of these three setup steps - http://communities.vmware.com/docs/DOC-14974

It's almost certain that PCoIP protocol is being blocked in your environment. Wireshark will help if you've double checked the 3 steps and it still fails.

Take a look at this - http://communities.vmware.com/message/1860942#1860942 which gives references to what you should do on the Security Server with Wireshark to see where PCoIP is being blocked.

Mark.

[ClayPowell]

Thank you for the information but the first article you linked to was the original article I used and followed to set up my environment.  I had tried previously and had issues so I scrapped the whole thing and started from scratch and followed that video to the letter.  (only difference I can see is that I have no DMZ and everything is on the local LAN with no firewall between the security server and the view desktops or connection/vcenter servers).

I too think it is something with the PCoIP being blocked but where I do not know as the only outbound rule we have to block anything is to restrict SMTP from anything except our Exchange server.  However, this is a different black screen error than what everyone else has reported with the blocked PCoIP issue so it is possible it is something else entirely.

I will follow the second article you posted in reference to using wireshark to track it down and see fif I can find anything there. 

Thanks again for the help and the info.

[griffinboy]

Not sure if that will help but here's what my FW rules look like:

host:

vdi.domain.com (public 1.2.3.4 IP which is the external VIP on my load balancers)

policy:

Source: ANY

Destination= vdi.domain.com

Service= HTTP (TCP 80), HTTPs (TCP 443), PCoIP (TCP 4172), PCoIP (UDP 4172)

Action= Allow

I do my NATing on the load balancers but it's the most basic NATing ever.

Is Windows Firewall dissabled on all your View machines?

[MauroBonder]

you´r using correct version of agent and view client ?

[ClayPowell]

the sonicwall rules look different but that is the basic idea.  the sonicwall does the nat'ing as well as the firewall and it has a wizard that basically does it all for you, just select/create your internal and external address objects and service/service groups and its done.  it creates a wan to lan rule for those services coming in on that public IP from anywhere.  the nat rules direct those services coming to the internal host and have reverse rules to nat the return traffic back out the same way.

yes, as i stated in my post, all firewalls are turned off

[ClayPowell]

yes, it works fine internally

[gekko]

Hi!

Check what the logfiles on the client says.

Located here (Win 7) : C:\ProgramData\VMware\VDM\logs

I would start with the debuglog.

I also think that either its a config error in View Manager or PCoIP is blocked in some way ..

regards

Kenth

[gunnarb]

Clay,

I'm not sure if you are aware but Mark Benson (above) pretty much wrote the book on this stuff.  Its most definately a port being blocked, but I understand you are probably tired of being told this so I'd like to just offer to dial in and help you out.  Also, if you can please use your phone and just record the screen of an attempted log in attempt.

Please feel free to email me directly at gunnarwb at gmail dot com.

I'll call you and we'll get this resolved.

Gunnar

[ClayPowell]

I am well aware of Mark's experience and if you refer to my response post to him I clearly stated that I too thought it was the protocol being blocked somewhere, just didn't know where. 

Without changing anything I tried logging in from a different remote location and was able to log in just fine... my environment was set up properly and as it should and was working fine... the issue turned out to be the firewall at the original test remote location.... for some reason or another it was blocking the returning PCoIP communication.  strange because the way the NAT policies were set up on that client it was supposed to allow return communication it the original communication was initiated by an internal client.  putting my remote client in the DMZ of the remote router fixed the issue for that remote site.  I have since tested it at several other locations and all has been well, it apparently was just this one location having problems. 

Thanks to all that posted and tried to help.  I followed the article Mark sent me to use wireshark and saw that communication was going out without problems it just wasn't making it back in from the internet.  telnetting on the ports from outside to the security server worked so I knew my firewall ports were opened properly so i started looking at the client i was connecting from.

Happy Holidays to all and thanks again for the responses!

[pornpol]

Hi ClayPowell,

I have got the problem too and found that black screen problem cause of network address translation doesn't work properbly. In a pcoip_server log, you have to prove that conect directly to view desktop following this :

SCNET :Server accepting connection from XXX.XXX.XXX.XXX:49272. << This IP is your security gateway.

SCNET :Server connecting on address XXX.XXX.XXX.XXX:4172.   << This IP is your view desktop.

MGMT_SSIG :Incoming session with: XXX.XXX.XXX.XXX  << This IP is your security gateway.

MGMT_SSIG :Client NATd address ( XXX.XXX.XXX.XXX  ) << This IP is your security gateway.

VGMAC :Client is NAT'ed!  << If you get this log, it's connect to view desktop compleltly

I found that IP is come from firewall instead of your security gateway, so NAT is not complete to route PCoIP to your view desktop if IP not from your security gateway.

Hope this help you.

Best Regards,

Silencer

[markbenson]

Just to be clear, the only way to support NAT with PCoIP is to have NAT between the client and Security Server. This is very common.

NAT with PCoIP is not supported between client and desktop (direct) or between Security Server and desktop.

Mark

[bwnets]

The quick and easy solution to this is to turn off IPS.

Problem solved.

I know running without IPS isn't recommended, so either configure the IPS settings to not block PCoIP (or whichever Intrusion signature it perceives it as) OR exempt the View Connection server from IPS.