PCoIP traffic getting dropped because it's using SSL

Showing results for 
Show  only  | Search instead for 
Did you mean: 

PCoIP traffic getting dropped because it's using SSL

L3 Networker

I have VMWare View clients and I'm trying to set up the rule with the vmware-view App-ID, but the traffic gets dropped at PCoIP. The PA logs are showing tcp/4172 as SSL, even though PCoIP has port tcp/4172 defined.



Is this an issue with the App-ID not identifying secure PCoIP?



Cyber Elite
Cyber Elite

Do you use application-default as service?

Try to change this temporarily to "any" to see if it works then.

Also add SSL to list of permitted apps.

If it starts working then it is probably because SSL has 443 as default port.

Don't leave service as any for long run but configure manually needed ports.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

Yes, I've added SSL to the permitted apps. I had it set to application-default.


When I set service to "Any", it works. But it still shows port 4172 as SSL.

Palo Alto firewall identifies application on any port.

It looks at traffic pattern and sees that this is actually SSL no matter what port it runs on.

Add your custom service and configure this manually instead of application-default (that allows ssl on 443 only).

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

So what is the point of the "vmware-view" app-id? I thought that was supposed to identify this traffic

Not sure if vmware view will keep on working but try to decrypt this traffic.

Will it still be identified as ssl?

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

No I haven't tried that yet. Thanks for the info

You will need to add ssl decryption to allow the firewall inspect the ciphered traffic.

you can also create a custom SSL application,





application-default means that if the traffic is coming on the default port it will be allowed. For example for SSL the defautl port number is 443. Now if the SSL traffic comes on port 8080 and the service is application-default PA will not allow that traffic because SSL is not coming on default port.

I think I understand that, but why does the PA identify certain SSL traffic by it's application name, while others are just "SSL"?


For example, Facebook is over port 443, but it doesn't say "SSL" in the logs, it says "facebook-base". Same thing for other pre-decryption applications, like Google.


So why can't the PA identifiy "vmware-view" instead of just "SSL"?

Facebook is easy to identify by the Common Name field of the certificate (generally *.facebook.com). Many other popular SSL applications work the same way. From that, the firewall can determine that while it is SSL, it's actually Facebook.


Your VMWare View app is likely going to a server with a private IP address, or is a doman name that is unknown to the application database. That's why it's only SSL.


If you decrypt the traffic, the firewall can see beyond the key handshake, and can identify the traffic by its actual requests and responses. Until you decrypt it, the firewall only has access to the handshake itself.

We run VMWare View (now Horizon) in our environment.  Our experience is that the built in vmware-view application did not work for us.  It seems to expect that all the services will run on one server, which is a little bit unrealistic.  I think Palo Alto should have split them down into their individual applications within View rather than trying to bundle them.  For instance, you may not want to allow RDP for instance, or USB redirection, but by default they are included.  When you start looking to block these it can get tricky and downright just not work because of “rules validation”.


In our case we have separate view hosting and security servers.  For us to get it to work correctly we had to configure custom applications, application overrides, and a few rules for view.  Note that View was the only application that we had to do this for.


Custom Apps:


view custom apps.jpg


Application Override


application override.jpg




view rules.jpg


Remember that PCoIP streams on UDP/4172.  The TCP/4172 side of PCoIP is used for control, which simply looks to be SSL traffic just on a custom port, which is probably why Palo Alto firewalls sees it as SSL.


I'm not a fan of having turn off layer 7 application inspection for these particular servers and ports, but this seemed to be the only option.  If anyone else has done this in a more simplified manner, I would love to hear about it.



Nice, thanks for taking the time to write an informative answer. I didn't know the other features such as USB were over a different port, I thought it was all tunneled over SSL.


When I look at my traffic, I'm only seeing ports 80, 443, and 8443. It seems everything is tunneled over SSL. We are using a VMAP server though, which all clients must connect to first. Maybe thats the difference?




Are you sure that your clients are configured for PCoIP?  Make sure you check the Horizon Client and make sure PCoIP is checked in the options.


If you are using a security server (such as for public facing clients), SSL will be used for the connection protocol and to encapsulate RDP (TCP) traffic.  PCoIP, from what I've experienced, is a completely different stream UDP stream that will be need to be allowed.


That being said, I didn't set up our View environment, so i can't speak to if its set up in accordance to best practices or not

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!