Support Center > Search Results > SecureKnowledge Details
ClusterXL: Accessing Standby cluster member through IPSec VPN Technical Level
Solution

There are two common problems that occur when a Standby cluster member is accessed through a VPN tunnel:

Drops by the Standby member's firewall inspection (referred to as "Standby drops" in the rest of the article):

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 be encrypted".

Drops by remote VPN peer due to replay counter verification error (referred to as "Peer drops" in the rest of the article):

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.

Note - This feature is currently not supported for SMB appliances.


This article explains how to overcome both challenges.

Versions R80.20 and higher:

A hotfix is required for versions lower than R80.20 Jumbo Hotfix Accumulator Take 76.

Refer to sk147493 for more details.

For the "Standby drops" problem, no specific configuration is required. Note that it is no longer recommended to set the fwha_forw_packet_to_not_active flag, in contrast to earlier versions.

To address the "Peer drops" problem, set the variable fwha_silent_standby_mode.

To set it on the fly, run this command:

# fw ctl set int fwha_silent_standby_mode 1      *

Versions R80.10 and lower:

To address the "Standby drops" problem, set the fwha_forw_packet_to_not_active flag on both members. To set it on the fly, execute the command below:

# fw ctl set int fwha_forw_packet_to_not_active 1     *

There is a workaround procedure to solve the "Peer drops" problem. The workaround procedure makes the Standby cluster member use its own IPSec SA for its local connections.

This requires the following two conditions to hold:

  • The Standby cluster member uses its private IP address (not Virtual IP address) for the encrypted connections.
  • Tunnel granularity is set to a single IP address for the Standby member's encrypted connections.

Workaround Procedure (example):

Active member's IP address: 0.10.10.101

Standby member's IP address: 10.10.10.102

Cluster's Virtual IP address:  10.10.10.100

To be able to access the Standby member's IP address 10.10.1.102 through ssh and ping - over an IPSec tunnel, follow these three steps:

  1. Cancel Cluster Hide for ssh and ping. Edit $FWDIR/lib/table.def on the Security Management and add ssh and icmp to the "no_hide_services_ports" table:

    no_hide_services_ports = { <0,1>, <22,6>, <4500,17>, <500, 17>, <259, 17>, <1701, 17>, <5500, 17>};

  2. Next, edit the file user.def** on the Security Management and add this line:

    max_subnet_for_range = { <10.10.10.100, 10.10.10.102; 255.255.255.255>};

  3. Install the policy to the cluster.

* See sk26202: Changing the kernel global parameters on all platforms to ensure that the modification survives reboot.

** Usually this is the $FWDIR/conf/user.def.FW1 file. See sk98239 for more details.

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment