Microsoft Lync Desktop Sharing Issue with Palo Alto

[pwoll]

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.