Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Matlu
Advisor

Meaning of Reject in Log

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"?

R4.png

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


0 Kudos
21 Replies
the_rock
Legend
Legend

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

0 Kudos
Matlu
Advisor

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.

R5.png

Cheers. 🙂

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
the_rock
Legend
Legend

Below is good reference...

Action Settings (checkpoint.com)

0 Kudos
Matlu
Advisor

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?

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
Matlu
Advisor

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

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
Matlu
Advisor

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

EV2.pngEV1.png

Thanks, Buddy 🙂

0 Kudos
the_rock
Legend
Legend

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

Andy

 

Screenshot_1.png

 

 Its in sv monitor, under tools...

 

 

Screenshot_2.png

 

 

 

0 Kudos
Matlu
Advisor

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?

R6.png

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

Cheers.

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
Matlu
Advisor

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

R8.pngR7.png

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.

0 Kudos
the_rock
Legend
Legend

SAM rules are applicable to gateway only.

0 Kudos
Matlu
Advisor

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.

0 Kudos
the_rock
Legend
Legend

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

 

👍

0 Kudos
the_rock
Legend
Legend

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]#

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
the_rock
Legend
Legend

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

 

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

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
rodborges
Explorer

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.

 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events