Saturday, July 11, 2015

Checkpoint Standby Cluster Member Interface Not Reachable

It was a curious test that I tried to ping other interfaces on Checkpoint 4200 Cluster's active and passive firewalls. The result was interesting, I were able to ping both active ( and standby ( interfaces which are at the same zone as test PC (, but not all of other interfaces on both cluster members. Only those active cluster member interfaces (such as are reachable. Standby cluster member's interface ( is unreachable at all. Not only icmp traffic, but also all other traffic such as https, ssh, sync traffic does not work on standby member's interface.

I did my search and found from Checkpoint Support Site, Checkpoint's explanation is "this is expected behavior. Connections to the Standby cluster members are not supported in HA clusters, by default."

To find out more details about this firewall behavior, I did some basic troubleshooting to see packets flow.

1. While I am pinging from  pc to standby member, I got echo timed out. But replied back

2. Check the drop packets from Active member, it seems the packets dropped by active firewall.It did not pass the traffic to standby member.

[Expert@CP1:0]# fw ctl zdebug drop | grep
;[cpu_0];[fw4_1];fw_log_drop_ex: Packet proto=1 -> dropped by fwchain_reject_mtu Reason: rejected;
;[cpu_0];[fw4_1];fw_log_drop_ex: Packet proto=1 -> dropped by fwchain_reject_mtu Reason: rejected;
;[cpu_0];[fw4_1];fw_log_drop_ex: Packet proto=1 -> dropped by fwchain_reject_mtu Reason: rejected;

Note: during the research, also SK97587 mentioned "in some cases when the traffic originates from the standby member, return traffic is forwarded from the VIP to the active member, which drops that traffic."

My old post "Check Point Cluster Member Gateway Drops Ping Packets Without Log in Smartview Tracker" has a similar symptoms as this case, but cause is different. The solution is enable simultaneous ping parameter in the kernel by this command:  fw ctl set int fw_allow_simultaneous_ping


The solution is pretty simple, there is a magic parameter in firewall kernel for this kind of situation:

[Expert@CP1:0]# fw ctl get int fwha_forw_packet_to_not_active
fwha_forw_packet_to_not_active = 0

Basically, when this parameter is set to "0", packet forwarding will NOT be done to a non-active member. Instead, a reset packet will be sent to the client.

Set following command on both Cluster Members:

# fw ctl set int fwha_forw_packet_to_not_active 1

With following command you can verify the setting:
# fw ctl get int fwha_forw_packet_to_not_active

To set it permanently to survive reboot, add this line to the file $FWDIR/boot/modules/fwkern.conf :

Then reboot. Perform this on both cluster members.


a. Troubleshooting "Clear text packet should be encrypted" error in ClusterXL


  1. Great explanation.

  2. Another solution exists. Instead of enabling something in the kernel you can set static routing so traffic to cluster members are routed directly to cluster members not to cluster VIP address. It have to be set at all interface where do you suppose income traffic to cluster members.

    Example: I try to connect to cluster members at ssh. I need to us IP addresses of the nearest FW interface so the traffic does not go through virtual cluster IPs. Or I can set static routes.

    Mgmt IPs::,, virtual
    Connection network IPs::,, virtual.
    - it is a connection network between FW and segments with administrators

    1. solution - use IPs
    Use instead of Use instead of

    2. solution - static routes and using Mgmt IPs
    Static routes at routers/L3 switches behind FW:
    ip route name Route_to_FW1_through_FW1
    ip route name Route_to_FW2_through_FW2

  3. Solution #2 worked fine in my case. thanks.

  4. Worked for me. Added on the fly command and the standby member started responding. Nice post.Thanks.