Hey Juniper stop messing with my Skype for Business Desktop Share

By | October 13, 2016

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.

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”



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:

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

8 thoughts on “Hey Juniper stop messing with my Skype for Business Desktop Share

  1. soder

    “I don’t have an account with Juniper, so unable to share my findings”

    Cannot you register a free account so that clueless indian support engineer can be enlightened?

    1. mlamontagne Post author

      Ha! tried that, but don’t have an authorization code…. “A Juniper Networks user account enables authorized users to access secure online resources. Before you begin, please ensure that you have the appropriate information. If you or your company have been given an authorization code from Juniper, please have that available. Support customers who do not have an authorization code will require a Juniper product serial number.”

  2. JeffCSP

    Great article with detailed troubleshooting references. Definitely will save for future reference!


  3. Mr Lahey


    Thanks for this article – it sorted my problems today. We put in a new Lync 2013 Edge pool last Saturday in our new DC with a DMZ managed by an outsourced partner. Everything worked well apart from desktop sharing, presentations and file transfer. This only impacted internal to external users and vice-versa and federated to internal users and vice-versa. Sometimes it all worked and other times it didn’t with ” We couldn’t connect to the presentation because of network issues”. Although we didn’t get the ICE warnings above (we were getting other codes which didn’t seem to tell us much) we could see on wireshark (Lync client and Edge server) masses of TCP resets and retransmissions. After 2 days of conference calls with our outsourced network provider, I forwarded this article to their Juniper guy who actioned your advice. So far so good and many thanks for posting up this information.

    Mr Lahey

  4. throwaway23451


    Did you try doing persistent nat for the addresses that are using Skype4B? Disabling TCP syn-check seems like a terrible idea, not sure why that would be the first choice and that the network engineers would agree to do that. I know you mention that you’re not a networking expert but checking the syn on TCP is a huge part that shouldn’t be turned off.

    1. mlamontagne Post author

      If persistent NAT means bidirectional(1:1) NAT, that is the only supported way for Skype for Business Edge servers. Issue has occurred in environments routing Public IPs or 1:1 NAT to the Edge.

  5. chrosik

    You can see the reason for the behavior in the Wireshark screenshots.

    The client sends a SYN packet and the server responds with a RST. So the Juniper firewall marks the open session for deletion (after 2 seconds, as is standard behavior). But less than 1 second later, the clients sends a new connection attempt with the same parameters (source IP + port, destination IP + port, protocol), which is the accepted by the server. But for the firewall it is the same session, which is still open (and marked for deletion). So about 1,5s after the TCP connection is established, the firewall session is terminated and no further data can pass through.

    Because disabling tcp-syn-check and tcp-seq-check globally on the perimeter firewall is not very secure, we blocked the TCP high port communication to SfB proxies instead. As this traffic can be also multiplexed through TCP 443 port, it works for us without decreasing the existing security.


Leave a Comment