> Source: [sk93204](https://support.checkpoint.com/results/sk/sk93204) # sk93204 - ClusterXL: Accessing a Standby Cluster Member through IPSec VPN | Property | Value | |----------|-------| | Solution ID | sk93204 | | Date Created | 2013-06-18 | | Last Modified | 2023-10-25 | | Technical Level | General | | Products | Security Gateway | | Versions | R81.20, R81.10 (EOS), R81 (EOS) | ## Solution When accessing a Standby cluster member through a VPN tunnel, two common problems can occur: **Peer Drops** and **Standby Drops** . **Peer Drops** Peer Drops occur when the Standby member reuses old replay counter values, leading to packet drops by the VPN peer. When the Standby member encrypts its outgoing traffic, it uses the same IPSec Security Association (SA) as the Active member, and re-uses old replay counter values. This causes the VPN peer to suspect a replay counter attack and drop the packets. **Standby Drops** Standby drops happen when decrypted packets are forwarded from the Active member to the Standby member. IPSec packets sent to a cluster in ClusterXL High Availability mode are always decrypted by the Active member. This includes the Standby member's local encrypted connections. In other words, VPN connections to a Standby member are always routed through the Active member. If the Active member forwards decrypted packets to the Standby member, then the Standby member drops the packet with the error "Clear text packet should have been encrypted". **To address Peer Drops...** Versions R80.40 and higher: Enable the fwha_silent_standby_mode kernel parameter to address Peer Drops. The parameter can be set on-the-fly with \`fw ctl set int fwha_silent_standby_mode 1\` and made permanent using the procedure in [sk26202](https://support.checkpoint.com/results/sk/sk26202 "sk26202: Changing the kernel global parameters on Check Point Security Gateways"). **NOTE:** If the Gateways IPs are NATted then this procedure will not work with SecureXL as the NATed traffic is not being accelerated. The workaround is to exclude the relevant IPs followed sk104468, and added the NAT IPs of both members to the table which excludes them from acceleration. Versions R80.20 and R80.30: A hotfix (PMTR-30582) is required to enable the fwha_silent_standby_mode kernel parameter. This hotfix was integrated into R80.20 Jumbo Hotfix Accumulator Take 80 and R80.30 Jumbo Hotfix Accumulator Take 76. Once the hotfix is installed, enable the fwha_silent_standby_mode kernel parameter to address Peer drops. The parameter can be set on-the-fly with \`fw ctl set int fwha_silent_standby_mode 1\` and made permanent using the procedure in [sk26202](https://support.checkpoint.com/results/sk/sk26202 "sk26202: Changing the kernel global parameters on Check Point Security Gateways"). **Note:** For versions R77.20.XX and R80.20.XX, the necessary kernel parameters are not available. In order to take advantage of this feature, you must first upgrade to R81.10.XX. Once the upgrade is complete, refer to the procedure for versions R80.40 and higher. **To address Standby Drops...** Versions R80.10 and lower: Enable the fwha_forw_packet_to_not_active kernel parameter on both members to address Standby Drops. The parameter can be set on-the-fly with \`fw ctl set int fwha_forw_packet_to_not_active 1\` and made permanent using the procedure in [sk26202](https://support.checkpoint.com/results/sk/sk26202 "sk26202: Changing the kernel global parameters on Check Point Security Gateways"). **To address Peer Drops in versions R80.10 and lower...** In order to resolve Peer Drops on versions R80.10 and lower, the following workaround must be employed. The procedure requires the Standby member to use its private IP address for encrypted connections and set the tunnel granularity to a single IP address for the Standby member's connections. For example, in the following environment: Active member's IP address: 10.10.10.101 Standby member's IP address: 10.10.10.102 Cluster Virtual IP address: 10.10.10.100 To connect to the Standby member's IP address (10.10.10.102) using ICMP and SSH over an IPSec tunnel, follow these steps: 1. Edit table.def on the Security Management Server / Domain Management Server and add ICMP (IP protocol 1, port 0) and SSH (IP protocol 6, port 22) to the "no_hide_services_ports" table: Example for table.def modifications in the above scenario: no_hide_services_ports = { \<0,1\>, \<22,6\>, \<4500,17\>, \<500, 17\>, \<259, 17\>, \<1701, 17\>, \<5500, 17\>}; **Note:** Refer to [sk98339](https://support.checkpoint.com/results/sk/sk98339 "sk98339: Location of 'table.def' files on Security Management Server") to determine the precise location of the table.def file to modify depending on which versions are installed on the Security Management Server and Security Gateway Cluster in question. 2. Edit user.def on the Security Management Server / Domain Management Server and add the cluster member addresses and virtual IP to the "max_subnet_for_range" table: Example for user.def modifications in the above scenario: max_subnet_for_range = { \<10.10.10.100, 10.10.10.101, 10.10.10.102; 255.255.255.255\>}; **Note:** Refer to [sk98239](https://support.checkpoint.com/results/sk/sk98239 "sk98239: Location of user.def files on Security Management Server") to determine the precise location of the user.def file to modify depending on which versions are installed on the Security Management Server and Security Gateway Cluster in question. 3. Install the policy onto the Security Gateway Cluster. --- # Agent Instructions This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products. ## Navigating This Knowledge Base - **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt) - **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml) - **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}` - **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content