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.
Client reports that Desktop Sharing within a conference works internally but not externally, A/V no issues.
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.
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.
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”
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.1×46/topics/reference/configuration-statement/security-edit-rst-invalidate-session.html
Some settings that others have reported they needed to disable:
- 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.