topic Re: Why CP drops RST-ACK packets from client? in Firewall and Security Management

Why CP drops RST-ACK packets from client?

evlad — Sun, 28 Nov 2021 13:59:14 GMT

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,

Re: Why CP drops RST-ACK packets from client?

Timothy_Hall — Sun, 28 Nov 2021 15:06:27 GMT

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?

Re: Why CP drops RST-ACK packets from client?

the_rock — Sun, 28 Nov 2021 15:20:31 GMT

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

Re: Why CP drops RST-ACK packets from client?

evlad — Sun, 28 Nov 2021 21:05:53 GMT

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

Re: Why CP drops RST-ACK packets from client?

evlad — Sun, 28 Nov 2021 21:10:53 GMT

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

Re: Why CP drops RST-ACK packets from client?

evlad — Sun, 28 Nov 2021 21:22:35 GMT

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

Re: Why CP drops RST-ACK packets from client?

Chris_Atkinson — Sun, 28 Nov 2021 23:41:37 GMT

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

Re: Why CP drops RST-ACK packets from client?

the_rock — Mon, 29 Nov 2021 00:10:39 GMT

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.

Re: Why CP drops RST-ACK packets from client?

emmap — Mon, 29 Nov 2021 06:05:47 GMT

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.

Re: Why CP drops RST-ACK packets from client?

evlad — Mon, 29 Nov 2021 07:24:05 GMT

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!

Re: Why CP drops RST-ACK packets from client?

emmap — Mon, 29 Nov 2021 07:29:22 GMT

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.

Re: Why CP drops RST-ACK packets from client?

evlad — Mon, 29 Nov 2021 10:44:05 GMT

Thank You for answer!

Re: Why CP drops RST-ACK packets from client?

max71 — Tue, 16 May 2023 12:52:24 GMT

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