Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
evlad
Participant
Jump to solution

Why CP drops RST-ACK packets from client?

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,

 

0 Kudos
1 Solution

Accepted Solutions
emmap
Employee
Employee

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.

View solution in original post

0 Kudos
12 Replies
Timothy_Hall
Champion
Champion

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?

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
evlad
Participant

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

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
evlad
Participant

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

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.

0 Kudos
emmap
Employee
Employee

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.

0 Kudos
evlad
Participant

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!

0 Kudos
emmap
Employee
Employee

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.

0 Kudos
evlad
Participant

Thank You for answer!

0 Kudos
evlad
Participant

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

0 Kudos
Chris_Atkinson
Employee Employee
Employee

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

CCSM R77/R80/ELITE
0 Kudos
max71
Explorer

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events