When working on network device monitoring project, there is interesting thing happened on Check Point cluster gateways. I am not able to ping active cluster member. Also surprising thing is there is no log in Smartview Tracker.

Symptoms: 

Cluster member 1 is active and having ip address 172.17.3.35. Cluster member 2 is standby and having ip address 172.17.3.36. Cluster virtual ip is 172.17.3.34. Network Monitoring software uses ping to decide if both cluster members alive or not to decide to send out alarming email.

Interesting thing is I am able to ping 172.17.3.34 (VIP) and 172.17.3.36 (Secondary Cluster member), but not 172.17.3.35 (active cluster member)

I did a test from server 172.17.3.83 which is same zone as firewalls interfaces locating.

From active cluster member gateway expert mode, use fw ctl zdebug drop command, I got some dropped packets log:

;[fw4_0];fw_log_drop_ex: Packet proto=1 172.17.3.83:2048 -> 172.17.3.35:43221 dropped by fw_handle_first_packet Reason: fwconn_key_init_links (INBOUND) failed

drop1.png?resize=640%2C32drop1.png?resize=640%2C32

Causes:

Check Point sk26874 (Cannot simultaneously ping Virtual IP address of the cluster and IP addresses of physical interfaces on cluster members from a remote host) has well explanation the cause regarding this kind of drop:

  1. When the Check Point Security Gateway / cluster member creates an ICMP connection in the Connections Table, a dummy port is allocated in order to make this connection unique (since ICMP packets do not have real port numbers). The dummy port is calculated based on protocol-level session IDs.

    Under certain conditions, the dummy port is calculated to be the same for multiple connections, which causes a conflict in the Connections Table, causing the drop.

  2. In ClusterXL configured in High Availability New Mode / VRRP cluster , the ICMP Request sent to Cluster VIP address and to the IP address of the physical interface on Active/Master member, are processed by Active/Master member (“NAT-folded” from physical IP address of Active member). Since these two ICMP Requests have the same parameters, Active/Master member is not able to distinguish between them. As a result, the first of these two ICMP Requests will be processed correctly, and the second of these two ICMP Requests will be dropped.

Solutions:

step 1. Change on the fly but not survive a reboot

fw ctl set int fw_allow_simultaneous_ping 1 

step 2. Permanent Changes on the gateways:

Edit the $FWDIR/boot/modules/fwkern.conf
add following line in:

fw_allow_simultaneous_ping=1 


3. Verify the value of fw_allow_simultaneous_ping
fw ctl get int fw_allow_simultaneous_ping 

Reference:

Updates:

There is new post for another scenery Checkpoint firewall dropped the packets in the kernel without logged into SmartTrack and I recorded into the following link: