Why CP drops RST-ACK packets from client?

[evlad]

Something that I can not fully understand:
Firewall stands between Client and Server, Client working with any application on Server side through usual HTTPS session. They talking, exchange data... after small pause (1-2 min, not longer) RST-ACK packet suddenly sent from Client to Server.
And FW drop it because the packet "doesn't SYN" (I see many of them all in the LOG)!?
Why? How FW knows BEFORE Client that session was closed/terminated?
Client doesn't know this. Client may be mentioned that smth wrong in the session and wants to close it (RST). Why FW intercepts? The timeout for dead sessions is 1Hour (by CP default) and 1-2 minutes of silence is very-very far from 1Hour...

Any guru explanations will be appreciated,

[Timothy_Hall]

Without seeing a packet capture showing the context in which the firewall dropped the RST-ACK it is not possible to determine why it was dropped.  Please provide a capture as well as the actual drop log card for this.

It is also possible that you are running afoul of the IPS Core Activation "Spoofed Reset", is that signature enabled in your environment?

Also any chance that there is a duplicate IP address assigned for the client?  Is the RST-ACK packet coming from the same Layer 2 MAC address involved with the successful connection packets?

[evlad]

Tanks Timothy!
I will try to get Capture. But I can do this only on the FW, not on the client. Because client somewhere in the Internet (distance of many hops) and I have no possibility to ask him participate in debug (install wireshark or smth like this).
For the same reason I don't think the MAC on layer 2 matter...

And I will check "Spoofed Reset" Signature on IPS, thank You

[the_rock]

If by "doesn't SYN" (I see many of them all in the LOG)!? you mean "first packet isnt SYN? Is that what you see in the logs? If so, there could be many reasons...first, I would start by disabling securexl and see if issue goes away, but @Timothy_Hall is 100% right, we need to see packet capture to have better understanding.

Also, check out below, might be helpful:

https://community.checkpoint.com/t5/Security-Gateways/First-packet-isnt-SYN-r80-20/td-p/76108

Andy

[evlad]

O yes! I mean "first packet isn't SYN"... sorry about my english.
In fact I can simplify the question: how FW concludes that this is FIRST packet, not continuation of existing session? (Consider that You see sequence of accepted packets from that source IP to that Server IP just one minute before.)

[the_rock]

Hey, no worries, all good. Well, to answer your question, in simple terms, it could be determined by possibly how aggressive aging is configured and TCP timeout settings. Cant state that for certain in your case, but if you check the link I sent in my first response, it actually gives a pretty good explanation.

[emmap]

The client may have sent a FIN packet earlier and not received a response, which would put the connection into a close_wait state and then timed out of the FW connection table after 5 or 20 seconds (depending on version). Then if the client is waiting another minute before RST-ACK'ing the connection out of its connection table, the connection would no longer be in the connection table on the gateway, and hence dropped out of state.

[evlad]

emma, thank You so much!
This is very interesting scenario and it make sense for me. So, beside the session timeout defined 1Hour(3600sec), beside Aggressive Aging defined 10min(default), the FW has some another timeout defined 5 or 20 sec for connections in a "close_wait state"...  and the FW switch the connection to close_wait state when it met the FIN packet from any side of the connection, right?
I never read about this timeout and I will check... thank You!

[emmap · Accepted solution]

It's in the global properties > Stateful Inspection, under TCP end timeout. Basically, it's how long the gateway will wait for a FIN-ACK after seeing a FIN, or a RST-ACK after seeing a RST. Due to this, seeing RST-ACKs being dropped is pretty normal. OSs will often send a RST-ACK to close out a half-open/half-close connection, which generally won't match an existing connection.

[evlad]

Thank You for answer!

[evlad]

... and yes - it's a Cluster. But I don't think the issue related ClusterXL because all LOG messages came from the same origin (same node) that is Active

[Chris_Atkinson]

Are you able to provide more context, does this happen only when the firewall policy is installed, how is your connection persistence configured?

[max71]

Hi , today i have the same issues .. i do not see ant RST packet from client , but the firewall drop after RST ACK.

Have you solve the problem ? How ? thank you very much.

Max