Packet is dropped. I do not know why is reason.

[DaeGyu_Kyoung]

Hi CP engineers !

Test environment

Version : MGMT(R80.20), FW(R80.10), Both not JHF

model : MGMT(Dell Openserver), FW(SG5x00)

I am very odd experience packet drop on CheckPoint firewall.

1. I made a rule to pass the packet.

2. I also made a manual NAT rule to translate the packet.

3. when I execute the command "fw ctl zdebug + drop, fw monitor -e" , saw the packet is dropped

Below it is that Things I've done. (Rule number is example)

1. When tested only with Manual NAT, the packet is dropped.

-> Manual NAT Rule 10

2. when I added the rule Automatic NAT and deleted Manual NAT, packet was passed.

-> Because of Automatic NAT Rule 20, no Manual NAT exist

3. when I added Manual NAT same with automatic NAT, packet was passed.

-> Only Manual NAT (NAT Rule 10), Automatic NAT (NAT Rule 20)

Packet is passed because of NAT Rule 10(Manual NAT)

when I added only Manual NAT, I think the action have to be running well. But if the automatic NAT does not exist, Manual NAT is not running and the packet is dropped because of No MATCH rule. I do not know why is reason.

I upload the file zdebug result and NAT table.

[Tor-Erik_Ones]

try this capture, then you will see where its dropt
#fw monitor -e "(src=10.10.10.10) or (dst=10.10.10.10),accept;" -p all
if oyu whant to excam it in wireshark or some other you can add the line under to make the output to a file

-o /tmp/capture.cap

[Tor-Erik_Ones]

but drop reason are Roulebased drop - NO MATCH. So how does you firewall roule look like, are you using your internal IP adress or are you using your NAT adress?

BTW
If its not matching any roules... don't you have a cleanup roule? as far that i know its recomanded and bestpractice (or atleast it was, unsure if it changed in R80...)

[PhoneBoy]

A cleanup rule is still added in R80.x, though whether it is an "Accept" or "Drop" depends on how the layer is configured.

Further, if you do not have an explicit cleanup rule, you will see the "implicit" cleanup rule show up as a comment at the end of the rulebase with a note the traffic will NOT be logged.

[DaeGyu_Kyoung]

Rule exists about the packet on the number 20.

I make a rule internal IP. 

[Borut]

I was also dealing with this error today and stumbled on this thread. I didn't find the answer but thought I would share how I resolved it.

The symptom was there was nothing in the logs for some connections after instaling JHFA T191 on R80.30 appliance. fw ctl zdebug drop | grep x.y.z.a revealed this drop reason.

@;1281124;[cpu_0];[fw4_1];fw_log_drop_ex: Packet proto=6 x.y.z.a:60458 -> x.y.z.a:443 dropped by fw_send_log_drop Reason: Rulebase drop - NO MATCH;

The fix was simple: Policy install on the gateway.

Borut

[FelipeTropeia]

Hi All,

I have just updated from R80.30 GA 155 take to R80.30 GA 191 take and noticed the same behaviour as Borut

@;815760;[cpu_1];[fw4_2];fw_log_drop_ex: Packet proto=6 y.y.y.y:18732 -> x.x.x.x:443 dropped by fw_send_log_drop Reason: Rulebase drop - NO MATCH;

After I pushed policy out all packets being matched in their respective rules.

[MikeB]

We experience same behavor yesterday upgrading a customr Cluster from R80.10 to R80.30 HF 196. We had to reinstall policies to get it right. 

Any clues as to what may be causing this behavior?

[Marc_Suelzle]

We had similar behaviour while upgrading a 4-node VSX cluster from R80.10 to R80.30 with HFA Take 214 last week.

ICMP were passing the gateways whithout any flaw but at least TCP connections were dropped with "dropped by fw_send_log_drop Reason: Rulebase drop - NO MATCH;". No Logs in SmartLog. After re-installing all policies on all virtual systems, the problem disappeared. With an unplanned outage of more than one hour.

I opened a support ticket but the root cause could not be found.