For me 2016 will be the year Juniper (specifically SRX) attacked Skype for Business desktop sharing. I figured it was time to document at least one of my battles.
Let me first start this post with the fact that I am not a networking expert, but have become an expert at finding network problems and convincing a network resource what they need to do to fix it.
Scenario:
Client reports that Desktop Sharing within a conference works internally but not externally, A/V no issues.
First thoughts:
Since A/V is most likely using UDP and Desktop Sharing is TCP (yes Video Based Screen Sharing (VBSS) prefers UDP, but RDP only uses TCP and RDP signalling is always maintained for failback).
Also we need to focus our efforts around the Edge, as no issues internally.
Next Steps:
History tells me that either the issue is the NAT is not bidirectional, DNS resolution issues on the Edge or Network. Of course the first two are easy to rule out with access to the Edge.
Time to fire my canned email to the client’s network team: “Skype for Business A/V is not having an issue which is leveraging UDP, we need to look at what could be messing with the TCP stream that Desktop Sharing uses. This almost is 100% a router or firewall configuration and usually due to deep inspection features especially on SSL.”
Well no luck with that email, time to trace and prove.
Client log (Lync-UccApi-0.UccApilog) in Snopper:
CLS logging in Snooper:
Important info:
BYE message indicating that “Call failed to establish due to media connectivity failure when one endpoint is internal and the other is remote”, MediaType of “Application-sharing”. Let’s note the LocalAddress port of 25221 to easily search in the WireShark captures, also the ICEWarn of 0x8000100.
Time to fire up the ICE Warning Flag Decoder (
https://gallery.technet.microsoft.com/office/ICE-Warning-Flag-Decoder-97058ef3)
So we have: “there is no direct TCP connection possible”.
On to Wireshark, filtering with “tcp.port==25221”
Client:
Edge:
Juniper SRX:
Important info:
Well I know that the black lines are “BAD TCP” and the red are “TCP Resets”, which always makes me worry. WireShark Packet colorization:
https://www.wireshark.org/docs/wsug_html_chunked/ChCustColorizationSection.html
What’s interesting is the Juniper SRX is reporting “TCP Out-Of-Order”, so we know this device is watching the TCP session and resetting what it doesn’t like.
After a bit of googling I came up with a list of settings for the network resource to disable on the SRX:
- tcp-syn-check (TCP Syncro Check:)
- tcp-seq-check (TCP Sequence Check)
Note: How to selectively disable TCP SYN or Sequence checking: https://kb.juniper.net/InfoCenter/index?page=content&id;=KB25094&actp;=search
Magic! We’re in business and no Desktop Sharing issues externally anymore.
Another one of my battles the client had the TCP syn/seq already disabled, but also had to add:
- tcp-rst-invalidate-session: https://www.juniper.net/documentation/en_US/junos12.1x46/topics/reference/configuration-statement/security-edit-rst-invalidate-session.html
Some settings that others have reported they needed to disable:
- tcp-syn-bit-check
- alg sip enable
Looking at the Juniper forums there’s an open topic on this issue: https://forums.juniper.net/t5/SRX-Services-Gateway/Skype-Business-desktop-sharing/td-p/291272, I don’t have an account with Juniper, so unable to share my findings.
Juniper update: [SRX] Desktop Sharing and File Transfer in Microsoft Skype for Business clients fail to pass through SRX