CCP drop packets in R81

[Ramasubramaniya]

Hi Team,

We are in a progress of migrating the Checkpoint hardware from 4400 to 6600.

Old hardware is running on R77.30 and new hardware is already upgraded to R81.

Old hardware running with VRRP Cluster

New hardware running with ClusterXL

Both hardware are connecting on same switch

But the new Firewall cluster is experiencing the below error message.

@;162960;[vs_0];[tid_3];[fw4_3];fw_log_drop_ex: Packet proto=17 0.0.0.0:8116 -> 10.0.0.0:8116 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "Network" rule 781;
@;162960;[vs_0];[tid_0];[fw4_0];fw_log_drop_ex: Packet proto=17 0.0.0.0:8116 -> 10.0.0.0:8116 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "Network" rule 781;
@;162960;[vs_0];[tid_1];[fw4_1];fw_log_drop_ex: Packet proto=17 0.0.0.0:8116 -> 10.0.0.0:8116 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "Network" rule 781;
@;162960;[vs_0];[tid_2];[fw4_2];fw_log_drop_ex: Packet proto=17 0.0.0.0:8116 -> 10.0.0.0:8116 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "Network" rule 781;
@;162961;[vs_0];[tid_3];[fw4_3];fw_log_drop_ex: Packet proto=17 0.0.0.0:8116 -> 10.0.0.0:8116 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "Network" rule 781;
@;162961;[vs_0];[tid_0];[fw4_0];fw_log_drop_ex: Packet proto=17 0.0.0.0:8116 -> 10.0.0.0:8116 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "Network" rule 781;
@;162961;[vs_0];[tid_1];[fw4_1];fw_log_drop_ex: Packet proto=17 0.0.0.0:8116 -> 10.0.0.0:8116 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "Network" rule 781;
@;162961;[vs_0];[tid_2];[fw4_2];fw_log_drop_ex: Packet proto=17 0.0.0.0:8116 -> 10.0.0.0:8116 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "Network" rule 781;

[the_rock]

Is that implicit clean up rule number 781?

[Ramasubramaniya]

Yes it is a implicit deny rule 

[the_rock]

You may wish to engage TAC, because to me, if you think about it logically, since I am pretty sure your rule base had not changed, there is no reason why this would be happening. I get its clusterXL instead of VRRP, but still. So based on the drop, it shows its UDP protocol and port 8116, which is clustering, so one thing I would try to do it maybe quickly just run zdebug only for port 8116 and also fw monitor for that specific port and see what you get.

Andy

[HristoGrigorov]

@Ramasubramaniya You don't happen to have implied rules disabled ?

[Ramasubramaniya]

You mean to Disable the implied rule?

We kept it to log the traffic getting denied on the firewall, and it's really important for troubleshooting

[HristoGrigorov]

No, I was asking if Implied Rules are already disabled. If they are enabled leave them like that; problem is somewhere else.

[Ramasubramaniya]

Anyone please help on this topic

[the_rock]

You may want to open support case, because this would need some more in depth troubleshooting, for sure.

[Yair_Shahar]

Hi,

Did sk132672 help you to resolve this issue?

Yair

[KostasGR]

Hello 

I think you are matching sk132672

BR,
Kostas

[the_rock]

Very good point Kostas!

[Ramasubramaniya]

Hi Team,

Thanks a lot for the kind replies. I tried sk132672 but does not help in my case.

As i already said the switch is connected with Current R81 Cluster and the R77.30 VRRP Cluster.

I lately realized this packets are coming from VRRP cluster since the Cluster mode is Mutlicast in the R77.30 Cluster.

I confirmed this by capturing packet on the R77.30 cluster and found same 0.0.0.0:8116 -> 10.0.0.0:8116 packets are exchanging over there.

So it's good say it's our design issue. Once again thanks all for the recommendations, much appreciated.

Ram T S