====== PFSense - Suricata - Alerts - SURICATA STREAM 3way handshake SYNACK with wrong ack ======

The best solution is to disable that rule.

----

When processing the TCP 3 way handshake (3whs), Suricata’s TCP stream engine will closely follow the setup of a TCP connection to make sure the rest of the session can be tracked and reassembled properly.  

Re-transmissions of SYN/ACKs are silently accepted, unless they are different somehow.  If the SEQ or ACK values are different they are considered wrong and events are set.  The stream events rules will match on this.

In some cases where not the initial SYN/ACK was used by the client, but instead a later one.  Suricata however, had accepted the initial SYN/ACK.  The result is that every packet from that point will be rejected by the stream engine. 

If people have the stream events enabled _and_ pay attention to them, a noisy session like this should certainly get their attention.  However, many people disable the stream events, or choose to ignore them, so a better solution is necessary.

----

===== Analysis =====

In this case the curious thing is that the extra SYN/ACK(s) have different properties: the sequence number is different.  As the SYN/ACKs sequence number is used as “initial sequence number” (ISN) in the “to client” direction, it’s crucial to track it correctly.  Failing to do so, Suricata will loose track of the stream, causing reassembly to fail.  This could lead to missed alerts.

Whats happening on the wire:

TCP SSN 1:

<code>
-> SYN: SEQ 10
<- SYN/ACK 1: ACK 11, SEQ 100
<- SYN/ACK 2: ACK 11, SEQ 1000
-> ACK: SEQ 11, ACK 101
</code>

TCP SSN 2:

<code>
-> SYN: SEQ 10
<- SYN/ACK 1: ACK 11, SEQ 100
<- SYN/ACK 2: ACK 11, SEQ 1000
-> ACK: SEQ 11, ACK 1001
</code>

It’s clear that in SSN 1 the client ACKs the first SYN/ACK while in SSN 2 the 2nd SYN/ACK is ACK’d.  It’s likely that the first SYN/ACK was lost before it reached the client.  Suricata accepts the first though, and rejects any others that are not the same.