In a DBHA setup due to security policy/configuration mismatch on Check Point APMs, APMs may be put in a state synchronization "ready state" on the primary chassis resulting in traffic not passing the firewalls.
In a DBHA setup, after disabling CoreXL on 2 members of the cluster on the VRRP backup chassis, traffic can be affected on the primary due to a mismatch in security policy/configuration on the firewalls.To review, a firewall policy consists of both the rule set and the features enabled on the Check Point Security Gateway/Cluster Member. After disabling CoreXL on the VRRP backup chassis and then reloading the APM's, we found that tcp traffic (ie. an ssh session) was inconsistently able to connect, as opposed to when all APMs had the same policy/configuration. As noted, after disabling the CoreXL on the VRRP backup chassis and then reloading the APMs, their "sync" status (via cphaprob state) came up in an "active" state. On the primary, when the APMs booted up, each APM's "sync" status went into a "ready" state.
As noted in Check Point's secure knowledge article sk42096, this "ready" state can happen when there is a mismatch in CoreXL settings. The "ready" state, as stated by Check Point, means that traffic can be unreliable and may not pass when in this state.
There are a couple steps that can be taken to check the consistency of the policies on the firewalls in relation to CoreXL and to prevent the "ready" state from happening.
1. Disable the Check Point sync interface between chassis while doing maintenance.
2. "rsh" into the APM and check the
/etc/cp.boot/boot.conf file and ensure CoreXL is enabled on the APM before reloading.
With CoreXL disabled the output should be as follows: