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

If we look at the Desktop Sharing page in the Skype for Business Protocol Workloads poster, we can see where the media is supposed to flow in these scenarios

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.