TCP Flags – First Packet Is Not SYN

[RemoteUser]

Hi mates,

What exactly does the message “First packet isn't SYN and ACK in TCP flags or FIN-ACK” mean when it appears in the drop log?

Does this indicate asymmetric routing, where the firewall receives a packet that belongs to an existing TCP session but does not have the initial SYN packet in its state table?

Thanks

[simonemantovani]

One reason could be that a packet belonging to a session that it doesn't exist in the connection table; one reason could be that when the firewall receive the FIN packet for that session it removes immediately the connection fron the table, but for that specific communication more packets are sended to complete the closure of the connection, when these packets reach the firewall than they're dropped because any related session has been removed from connection table.

In this case you could work on timeout (and maybe also aggressive aging configuration).

Another reason, as you mentioned, could be asymmetric routing, in this case you should check if the out of state packet is reaching the active member of the cluster or not.

It could also depends on non-RFC compliant application.

So you could take a look at this SK to start to investigate: https://support.checkpoint.com/results/sk/sk31382 

[RemoteUser]

Hi Simone,

Thank you for the feedback.

I have a couple of questions, if you don't mind.

So, basically, does this mean that the firewall is dropping the connection because a FIN packet reached the firewall, but somehow the connection had already been closed without receiving the expected confirmation from the other side? Am I understanding this correctly?

Also, when you mention modifying the timeout, do you mean changing it under the global properties?

I thought asymmetric routing could also occur, for example, when I see in the logs that the source interface belongs to interface X while the destination belongs to interface Y, based on the routing information from ip r g.

Am I understanding this correctly?

[simonemantovani]

Hello

the reasons that could led to drop for out-of-state, as you could read also in the SK, are several and require investigation, asymmetric routing could be one of these (obviously you know the network infrastructure and you can verify if this is the case, for example you could use fw monitor to verify this scenario); in other case the issue could be due to the aggressive aging configuration for the specific service (and in this case you should find some logs about aggressive aging).

[Timothy_Hall]

Also see here for guidance, which depends on which TCP flags are set in the dropped out of state packet:

https://community.checkpoint.com/t5/General-Topics/First-packet-isn-t-SYN/m-p/7027/highlight/true#M7...