Meaning of Reject in Log

[Matlu]

Hello, world.

I have a ClusterXL, running R81.10.
We currently have a connection policy defined.

SRC: 10.7.52.128
DST: 192.168.216.214

The service that most consumes this source, is the SSH.
Suddenly, the "connection" was interrupted.

How can I rule out that the Firewall is responsible for this "interruption"?

I understand that it would be to check the logs. I have checked the logs, and I found a REJECT action, which leaves me with the question, is this action something normal in the Checkpoint?
Shouldn't I see "DROP"?

I get Reject, for a PING service, I have the impression that the user, as he lost the SSH connection, started to try the PING to that destination, and the Checkpoint, for some reason, started to register it with this action.

Is this normal?

Greetings. 🙂

[the_rock]

Hey bro,

Thats actually good question. See below links, hopefully they are useful. In layman's terms, all it tells you is that traffic will be denied either way, BUT, reject will send a message along with it and drop wont, thats all.

Andy

https://community.checkpoint.com/t5/Security-Gateways/Rejects-with-Drop-rules/td-p/113538

https://www.baeldung.com/linux/iptables-reject-vs-drop#:~:text=The%20REJECT%20rule%20immediately%20r....

[Matlu]

I have read the Link of the discussion that you have shared with me, but I have the doubt, if this applies also, when the action of your rule is in "Accept", because in my case, the rule is to "allow" a flow, not to deny it.

Cheers. 🙂

[the_rock]

Technically, if rule's action is accept, which it is, then we would need to examine the log in question and see why it shows rejected.

Makes sense?

Andy

[the_rock]

Below is good reference...

Action Settings (checkpoint.com)

[Matlu]

I understand a little more about the documentation.

In the comments that I see from the other forum that you shared with me, what I understand is that this REJECT action, makes more sense, when it is INSPECTION traffic (HTTPS INSPECTION, probably), or when it is IPS (intrusion prevention system) traffic.

In my case, the connection between source and destination is mostly through SSH.
Does it make sense to show this kind of log in the SmartConsole?

[the_rock]

Thats true, but its hard for me to say, unless I can see full details about the log from the smart console. Keep in mind, it also could be due to the fact that connection itself was closed prematurely, meaning 3-way handshake was never completed.

Andy

[Matlu]

Well, as long as I don't see a log that says "DROP" between my ORIGIN and DESTINATION, I defend my FIREWALL, hahaha.
Our problem was not. 😄

The Reject leaves me confused, but I'll handle the shared theory and the one in the documentation, and keep blaming the end server, hahahaha.

Cheers. 😄

[the_rock]

Honestly, as I said mate, if you can send all the log details here (just blur out any sensitive info), we may be able to give better explanation.

Andy

[Matlu]

I hope these images will be more useful to find a better explanation. 🙂

Thanks, Buddy 🙂

[the_rock]

There is your answer amigo : - ). Sooo...you need to confirm SAM rules you got defined in SV monitor.

Andy

 Its in sv monitor, under tools...

 

[Matlu]

At the moment, I can only find this "log" in the SAM, which has nothing to do with the destination I am looking for.

I understand that the SAM is no longer blocking that IP that was initially reported to me, right?

But how do I know if there is a rule in the SAM for that destination with which I had problems?

Cheers.

[the_rock]

It would show if you click on all gateways option in sv monitor or run command I gave in expert -> fw sam_policy get. That is, mind you, IF it still exists...

[Matlu]

This is what I get from the recommendations you give me.

I am still a bit confused about the SAM.
I am doing some research.

SAM works on Gateways, right? Or also on the SMS (SmartCenter) itself.

Thanks for your comments.

[the_rock]

SAM rules are applicable to gateway only.

[Matlu]

I understand.

However, I don't see any current data that relates to my target IP in question, probably, the SAM rule is not in effect.

Even so, according to the LOG I showed, I now understand that it was the SAM rule that "blocked" the ICMP traffic and "logged" it as a "REJECT".

However, according to the logs that I keep seeing, nothing tells me that it was the Firewall that cut the SSH connection between the source and the destination.

Thanks for your comments, bro.

[the_rock]

I get your logic. I would probably verify all this with TAC, but to me, based on what you showed so far, appears to be SAM rule related.

Have a nice weekend!

Andy

👍

[the_rock]

You can also run below to check.

Andy

[Expert@quantum-firewall:0]# fw sam_policy get
no corresponding SAM policy requests
[Expert@quantum-firewall:0]#

[_Val_]

This is a reject log for ICMP, unrelated to your SSH issue

[the_rock]

Hey bro,

Just saw an email stating you said this, so since I was not clear on it, wanted to clarify : - )

Andy

*****************

I have read the Link of the discussion that you have shared with me, but I have the doubt, if this applies also, when the action of your rule is in "Accept", because in my case, the rule is to "allow" a flow, not to deny it.

Cheers. 🙂

**************************

[_Val_]

Please double-click on one of the reject logs, and show us what it says.

[rodborges]

Hi all,

I've just had a similar situation, did you manage to understand what happened with you?

We had the connections being REJECTED by a SAM rule. The log did not have any information about the rule that was rejecting it.

We've reinstalled the policy and commuted the nodes (it's a cluster). After that it resumed normal operation.