topic Re: First packet isn't sync in General Topics

First packet isn't SYN

batmunkh_unubuk — Wed, 04 Oct 2017 02:44:53 GMT

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?

Re: First packet isn't sync

PhoneBoy — Wed, 04 Oct 2017 04:50:34 GMT

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).

Re: First packet isn't sync

dorj_erdeneochi — Wed, 04 Oct 2017 05:06:42 GMT

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

Re: First packet isn't sync

Danny — Wed, 04 Oct 2017 05:50:48 GMT

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

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

Re: First packet isn't sync

MK9 — Wed, 04 Oct 2017 07:00:24 GMT

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

Re: First packet isn't sync

Marco_Valenti — Wed, 04 Oct 2017 07:40:49 GMT

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

Re: First packet isn't sync

Timothy_Hall — Sat, 06 Jul 2019 21:03:44 GMT

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.

Re: First packet isn't SYN

HeikoAnkenbrand — Sat, 07 Jul 2018 13:13:55 GMT

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