- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
12-02-2015 06:13 PM
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
The symptoms they experienced were all the same
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
Create a policy
This has solved the issue for us.
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!