Description

This article explains why certain features of Skype for Business clients may not pass successfully through SRX devices.

Symptoms

Certain TCP-based features of Microsoft Skype for Business clients such as Desktop Sharing and File Transfer fail to work when the SRX is located between the clients and Microsoft A/V Edge Server.

Solution

This issue is related to the way Microsoft Skype for Business clients communicate to Microsoft A/V Edge Server.

A client establishes a TCP connection to the Edge Server, using dynamically chosen TCP ports. However, in order for this connection to be accepted, the clients must be first authenticated. The authentication is done in parallel, via a service called MRAS (Media Relay Authentication).

The details of this implementation are beyond the scope of this article. However, an important detail is that the Edge Server will reject the client's attempts to establish a TCP connection until the client finishes the authentication procedure.

As a result, the Edge Server might respond with TCP RST flag to a TCP SYN packet sent by the client (this happens when the authentication is still in progress).
The client will then retry the connection, using exactly the same TCP source/destination ports. Eventually, the TCP SYN will be accepted by the Edge Server, and the normal TCP 3-way handshake will continue (this will happen once the authentication is completed).

This is demonstrated in the following packet capture by the tcpdump tool on the Edge Server:

# First SYN
16:07:39.788462 IP (tos 0x0, ttl 63, id 39149, offset 0, flags [DF], proto TCP (6), length 60)
10.1.1.1.12340 > 20.1.1.1.1234: Flags [S] , cksum 0x9982 (correct), seq 1888073779, win 29200, options [mss 1460,sackOK,TS val 563159262 ecr 0,nop,wscale 7], length 0

# RST
16:07:39.788525 IP (tos 0x0, ttl 64, id 3885, offset 0, flags [DF], proto TCP (6), length 40)
20.1.1.1.1234 > 10.1.1.1.12340: Flags [R.] , cksum 0xb5d1 (correct), seq 0, ack 40123966, win 0, length 0

# Second SYN, almost immediately, same source/destination ports
16:07:40.301453 IP (tos 0x0, ttl 63, id 56041, offset 0, flags [DF], proto TCP (6), length 60)
10.1.1.1.12340 > 20.1.1.1.1234: Flags [S] , cksum 0x5504 (correct), seq 1896086455, win 29200, options [mss 1460,sackOK,TS val 563159390 ecr 0,nop,wscale 7], length 0

# This time - acknowledged
16:07:40.301524 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
20.1.1.1.1234 > 10.1.1.1.12340: Flags [S.] , cksum 0x9c69 (incorrect -> 0x1e7a), seq 1305095903, ack 1896086456, win 14480, options [mss 1460,sackOK,TS val 647613625 ecr 563159390,nop,wscale 4], length 0

Notice the second TCP SYN uses exactly the same source and destination port numbers and is sent almost immediately after the first attempt.

The default behavior on the SRX is to maintain a special invalidation timer that postpones session invalidation by approximately 2 seconds after the receiving of TCP RST.

In the described case, the following occurs:
  • The first TCP SYN passes through the SRX and successfully reaches the Edge Server. A pending flow session is created on the SRX.
  • The Edge Server responds with TCP RST. The SRX starts the above mentioned invalidation timer.
  • In the meantime, the client sends the second TCP SYN packet. It matches exactly the same pending flow session, since the entire 5-tupple (src/dst IP, src/dst port, protocol) matches it.
  • The packet reaches the Edge Server successfully, TCP 3-way Handshake continues, and the flow session gets eventually established. The communication between the client and the Edge Server starts.
  • However, approximately 2 seconds later, the invalidation timer expires, and the flow session gets invalidated on the SRX.
  • Subsequent packets will be dropped by the SRX, since they do not match an existing flow session anymore (and they cannot establish a new flow session, since these are not TCP SYN packets).
  • As a result, the communication between the client and the Edge Server "freezes", and the client eventually reports an error.

You can change the default behavior on the SRX by configuring the following option:

set security flow tcp-session rst-invalidate-session

This setting will invalidate a flow session immediately upon receiving a TCP RST packet. The client's second attempt to send the TCP SYN packet will create a new flow session because the previous one will be already invalidated at this point.

Here is the new sequence of events:
  • The first TCP SYN passes through the SRX and successfully reaches the Edge Server. A pending flow session is created on the SRX.
  • The Edge Server responds with TCP RST. The SRX invalidates the pending flow session immediately.
  • Now the client sends the second TCP SYN packet. There is no flow session to match this time, so the SRX creates a new pending flow session (this time it is possible, because the packet is TCP SYN).
  • The packet reaches the Edge Server successfully, TCP 3-way Handshake continues, and the new flow session gets eventually established. The communication between the client and the Edge Server starts.
  • The communication continues without issues, there is no reason to invalidate the new flow session.

Modification History

2020-04-13: Article reviewed for accuracy. No changes made. Article is correct and complete