Suricata

In a controlled test, the following has been observed:

1.      SYN             TS A    SEQ X   Accepted by Suricata, TS initialized to A
2. +1s  SYN resend      TS B    SEQ X   Accepted by Suricata, updated TS to B
3. +0s  SYN/ACK         TS A    ACK X   Dropped by Suricata because TS A != TS B
4. +1s  SYN/ACK resend  TS A    ACK X   Dropped by Suricata because TS A != TS B
5. +1s  SYN resend      TS C    SEQ X   Accepted by Suricata, updated TS to C
6. +0s  SYN/ACK resend  TS A    ACK X   Dropped by Suricata because TS A != TS C

... repeats this pattern for a few packets ...

Flow is considered timed out and evicted.

13. +9s SYN/ACK midstream pick up
... tls session treated normally 

In short, after receiving additional SYN packets after the first, Suricata wants the SYN/ACK to match the last SYN, not the first. However it appears that the server insists on responding to the first SYN. Note that the SYNs identical except for the timestamp option.

Because Suricata blocks the SYN/ACK packets it considers invalid, the connection stays in the NEW state, which means that the flow is evicted much more aggressively than an established flow.

Only once the flow is timeout out and a new flow is created midstream does Suricata allow it to pass fully.

If midstream is not enabled the behavior will depend on the stream.midstream-policy setting.