After spending alot of time trying to troubleshoot a problem where Lync Desktop Sharing failed when connecting to a Federated user, I found this wonderful blog by Tom-Inge Larsen. I am sharing it with his permission. It solved my problem. He also indicates that it appears to still be a problem in PAN v7.0.3. The full post can be seen at http://blog.codesalot.com/2015/09/28/desktop-sharing-issues-with-palo-alto-firewalls/#comment-4467
Earlier this year we were contacted by several customers reporting desktop sharing issues in scenarios involving participants on the outside of the firewall. These users fall in to two categories
Users belonging to the organization that are logged inn via the edge server – Edge server users
Users not belonging to the organization – Federated users
The symptoms they experienced were all the same
Desktop sharing fails intermittently in the following scenarios
One to one between federated and user logged in directly on FE
Fails for external users in both categories when participating in conferences
When a federated user or a conference is involved, the media is sent through TCP via the AVMCU on the edge server. So the issue seems to be with the outbound TCP 50000-59999 port range traversing the firewall.
The call fails with the following reason in the BYE:
Ms-client-diagnostics: 23; reason="Call failed to establish due to a media connectivity failure when one endpoint is internal and the other is remote"
The ICE warning is 0x8000100, which if looked up in the Reskit documentation or the ICE Warning Flags decoder, means this
TCP NAT connectivity failed
This flag is expected. If local-to-local connectivity succeeded, the TCP NAT connectivity check may not have been tried. Or there is no direct TCP connection possible.
TCP NAT connectivity failing may result in an ICE protocol failure.
Another clue pointing to the TCP media port range.
We also saw a lot of TCP retransmits when doing packet tracing, the edge server was not happy with the TCP connection when trying to set up the desktop sharing session.
What we realised fairly early was that all customers reporting this was running Palo Alto firewalls, which tries to look at what kind of application the traffic is in stead of the traditional just looking at port numbers.
After quite a bit of troubleshooting – everything was set up by the book, nothing seemed to be wrong other than the media failing – we were able to make a case with Palo Alto support, and it eventually turned out to be a bug in the Palo Alto software that doesn’t recognize the desktop sharing session as that, but tries to decrypt the session – even if no decryption is configured anywhere else on the firewall. The bug was as far as we can tell introduced in version 6.1.3, and has been reported fixed in an upcoming version 7.0.3. PAN support gave this workaround:
Create a custom application for port 443
Create an application override for port 443
This must be created for both incoming 443 traffic from the Internet to the Edge Server and outgoing traffic from the Edge Server to the Internet
Create a policy
Add policy rules referencing the custom application for both incoming and outgoing 443 traffic
This has solved the issue for us.
... View more
I have seen the same behavior, and it appears to still be unresolved. Categorization changes sometimes take several days to propagate through Brightcloud's infrastructure. Was there ever any projected resolution from PAN on this?
... View more
Wow, panos. You just saved me. I have spent hours trying to figure out why nothing shows up in the dropdown list in the Users tab in a policy rule. From your post, I learn that if I enter any text, then they show up! Thank you!
... View more