This article describes the issue of the SYN packet being dropped in the TCP session on an SRX device.
At times, the SYN packed sent by the client gets dropped by the SRX device, when the final ACK - used to close a session - is not received by the device.
The sequence of packets for 3-way and 4-way session close, is as follows:
4-Way handshake:
Client A Server B ======================== [1] FIN [2] ACK [3] FIN ---> session timer set to 150s [4] ACK ---> session timer set to 2s
---> session timer set to 2s
3-Way handshake:
Client A Server B FIN FIN/ACK ---> session timer set to 150s ACK ---> session timer set to 2s
At step [1], the session output should look like:
root> show security flow session session-identifier 59 Session ID: 59, Status: Normal Flag: 0x0 Policy name: test/4 Source NAT pool: interface, Application: junos-ftp/1 Maximum timeout: 1800, Current timeout: 1788 Session State: Valid Start time: 2848354, Duration: 20 In: 192.168.112.11/45671 --> 172.27.117.46/21;tcp, Interface: fe-0/0/2.0, Session token: 0x7, Flag: 0x0x21 Route: 0xb0010, Gateway: 192.168.112.11, Tunnel: 0 Port sequence: 0, FIN sequence: 0, FIN state: 0, Pkts: 7, Bytes: 313 Out: 172.27.117.46/21 --> 172.27.117.198/29648;tcp, Interface: fe-0/0/0.0, Session token: 0x6, Flag: 0x0x20 Route: 0xa0010, Gateway: 172.27.117.46, Tunnel: 0 Port sequence: 0, FIN sequence: 0, FIN state: 0, Pkts: 4, Bytes: 298 Total sessions: 1
At step [3] the session timer has been set to 150s and looks like:
root> show security flow session session-identifier 59 Session ID: 59, Status: Normal Flag: 0x80000000 Policy name: test/4 Source NAT pool: interface, Application: junos-ftp/1 Maximum timeout: 150, Current timeout: 150 Session State: Valid Start time: 2848354, Duration: 31 In: 192.168.112.11/45671 --> 172.27.117.46/21;tcp, Interface: fe-0/0/2.0, Session token: 0x7, Flag: 0x0x21 Route: 0xb0010, Gateway: 192.168.112.11, Tunnel: 0 Port sequence: 0, FIN sequence: 0, FIN state: 2, > Indicates that FIN and ACK have been received for this wing of the session Pkts: 10, Bytes: 439 Out: 172.27.117.46/21 --> 172.27.117.198/29648;tcp, Interface: fe-0/0/0.0, Session token: 0x6, Flag: 0x0x20 Route: 0xa0010, Gateway: 172.27.117.46, Tunnel: 0 Port sequence: 0, FIN sequence: 0, FIN state: 1, > Indicates that only FIN has been received for this wing of the session Pkts: 7, Bytes: 425 Total sessions: 1
At step [4], the session timeout has been set to 2s. As the session is about to be aged out, the session output should look like:
root> show security flow session session-identifier 59 Session ID: 59, Status: Normal Flag: 0x80000000 Policy name: test/4 Source NAT pool: interface, Application: junos-ftp/1 Maximum timeout: 150, Current timeout: 2 Session State: Valid Start time: 2848354, Duration: 31 In: 192.168.112.11/45671 --> 172.27.117.46/21;tcp, Interface: fe-0/0/2.0, Session token: 0x7, Flag: 0x0x21 Route: 0xb0010, Gateway: 192.168.112.11, Tunnel: 0 Port sequence: 0, FIN sequence: 0, FIN state: 2, < ACK has been received for FIN Pkts: 10, Bytes: 439 Out: 172.27.117.46/21 --> 172.27.117.198/29648;tcp, Interface: fe-0/0/0.0, Session token: 0x6, Flag: 0x0x20 Route: 0xa0010, Gateway: 172.27.117.46, Tunnel: 0 Port sequence: 0, FIN sequence: 0, FIN state: 2, < ACK has been received for FIN Pkts: 7, Bytes: 425 Total sessions: 1
If the final FIN for session closing has not been received by the SRX and the client sends a SYN to initiate a new connection, the SYN packet is likely to be dropped by the TCP out of sequence feature.
The packet flow is:
Client A Server B FIN ACK FIN > session timer set to 150s SYN > SYN packet may be dropped by out of sequence check
By default, TCP sequence checking is enabled to confirm if the out of sequence counters are incrementing:
root> show interfaces <interface name> extensive | match seq TCP sequence number out of window: 10
Note : This is a global counter for the interface; so the out of sequence counter increase may be due to other traffic.
We can reduce the TCP time-wait state. By default, the session timeout is set to 150s from step [3].
With the following command, the time-wait state timer can be changed to a lesser value to accommodate such irregular TCP connections:
set security flow tcp-session time-wait-state session-timeout<N>
In the above command, N denotes the timeout.
Note : The timeout may need to be adjusted to suit customer scenarios. So it is advisable to check and test customer topologies, to find the best timer settings for each topology.
2020-04-22: Article reviewed for accuracy; no changes required.