Support Center > Search Results > SecureKnowledge Details
ClusterXL: Accessing Standby member through IPSec VPN

There are two separate challenges that make it problematic to access Standby members over a VPN tunnel:

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

    IPSec packets sent to a cluster in ClusterXL HA mode are always decrypted by the Active member. This includes Standby member's local encrypted connections. In other words, VPN connections to a Standby member are always routed through the Active. If the Active member would just forward decrypted packets to the Standby, the latter would drop it with the error ""Clear text packet should be encrypted".

  2. 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 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.

This article explains how to overcome both challenges.

Versions R80.20 and higher:

A hotfix is required if running with a version 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, execute the command below:

# fw ctl set int fwha_silent_standby_mode 1      *

Versions R80.10 and lower:

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

# fw ctl set int fwha_forw_packet_to_not_active 1     *

Solving the "Peer drops" problem is trickier, but still possible with the workaround below. The idea is to make the Standby member use its own IPSec SA for its local connections.

This requires the following two conditions to hold:

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

Consider the following example:

Active member's IP address is

Standby member's IP address is

Cluster VIP address is

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

  1. First, 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 the following line:

    max_subnet_for_range = { <,;>};

  3. Lastly, install the policy to the cluster.

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

** Normally it will be $FWDIR/conf/user.def.FW1 file. Refer to sk98239 for more details.

Give us Feedback
Please rate this document