Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Ramasubramaniya
Participant

CCP drop packets in R81

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;

0 Kudos
12 Replies
the_rock
Authority
Authority

Is that implicit clean up rule number 781?

0 Kudos
Ramasubramaniya
Participant

Yes it is a implicit deny rule 

the_rock
Authority
Authority

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

0 Kudos

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

Ramasubramaniya
Participant

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

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

Ramasubramaniya
Participant

Anyone please help on this topic

0 Kudos
the_rock
Authority
Authority

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

0 Kudos
Yair_Shahar
Employee
Employee

Hi,

 

Did sk132672 help you to resolve this issue?

 

Yair

KostasGR
Collaborator

Hello 

I think you are matching sk132672

BR,
Kostas

the_rock
Authority
Authority

Very good point Kostas!

0 Kudos
Ramasubramaniya
Participant

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

0 Kudos