First packet isn't SYN

[batmunkh_unubuk]

my gateway R80.10 and multicast cluster working. but internet is very slow and didnot drop any packet. 

only one drop packet is below picture. how can i solve this issue?

[PhoneBoy]

For TCP connections, the first packet the Security Gateway expects to see is a TCP SYN.

This packet would then be evaluated by the rulebase to determine whether or not the connection is permitted.

If it sees a TCP packet that is not a SYN and it can be associated with an existing allowed connection, then the packet will pass.

In the case where the TCP packet is NOT a SYN and cannot be associated with an existing connection, you see this error.

If you search on the phrase "First packet isn't SYN" in SecureKnowledge, there are several possible reasons this might occur.

In your case, it looks like a FIN-ACK packet has been received.

These are associated with closing a TCP connection gracefully.

The Security Gateway had already aged out the connection from the connections table, which happens after the TCP End Timeout (40 seconds by default, as I recall).

[dorj_erdeneochi]

How can we resolve this ? do we increase the TCP end timeout?  

[Danny]

Yes, this would be an option to consider and try.

Another option would be configuring and exception as described in sk11088 with sk98239.

[Marco_Valenti]

create a new service for the interested connections and increase his session timeout if it is really needed

do not modify stateful inspection settings or any file on your management

[MK9]

I would first check routing. Make sure, out and in packets use same route and same checkpoints inerface.

[Timothy_Hall · Accepted solution]

If I see an "out of state" error and the TCP flags involved are FIN and/or RST, I generally ignore them as they tend to be harmless in the majority of cases.  It simply indicates that the subject connection was not terminated cleanly as far as the firewall is concerned; this can be caused by many things including poorly-written applications and transient network and/or system problems.  However if these "out of state" logs for RST/FIN are conclusively correlated with application performance problems, TCP state logging (sk101221) and sending a TCP RST upon connection expiration (sk19746) can be useful here.  The former SK was covered in my book, while the latter SK was mentioned in the addendum to my book available for free at the URL below.

But the following combinations in an "out of state" error message will tend to get my attention:

SYN-ACK - Strong indicator of asymmetric routing on the forward path (from the connection's perspective), where the firewall is only seeing the return direction of the TCP 3-way handshake.

ACK all by itself - Probably asymmetric routing on the return path (from the connection's perspective).

ACK accompanied by PSH (or perhaps just ACK by itself) - The connection was timed out by the firewall due to inactivity. 

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[HeikoAnkenbrand]

The issue with FIN-ACK can also arise if you have software blades (HTTPS interception,...) on that check the content.

For HTTPS see:

TCP [FIN-ACK] packets for HTTPS traffic are dropped as out-of-state after enabling HTTPS Inspection 

Regards

Heiko