sk183052 - Remote Access VPN client fails to connect to (or disconnects from) the VPN Virtual System when it connects through another Virtual System on a Scalable Platform in the VSX mode

Remote Access VPN client fails to connect to (or disconnects from) the VPN Virtual System when it connects through another Virtual System on a Scalable Platform in the VSX mode

Product: ElasticXL, Maestro HyperScale Firewall, Remote Access VPN, VSNext, VSX (Traditional)

Version: R82

OS: Gaia

Last Modified: 2025-04-20

Symptoms

Remote Access VPN client fails to connect, or disconnects and reconnects to the VPN Virtual System when it connects through another Virtual System on a Scalable Platform in the Traditional VSX mode.

(Remote Access VPN client) -- (Virtual System) -- (Virtual Switch) -- (VPN Virtual System) — (Internal Network)

Remote Access VPN client fails to connect, or disconnects and reconnects to the VPN Virtual Gateway when it connects through another Virtual Gateway on a Scalable Platform in the VSNext mode.

(Remote Access VPN client) -- (Virtual Gateway) -- (Virtual Switch) -- (VPN Virtual Gateway) — (Internal Network)

In SmartConsole / SmartView, the security logs from the intermediate Virtual System / Virtual Gateway show that its Clean Up rule drops the encrypted responses the VPN Virtual System / VPN Virtual Gateway sends to the Remote Access Client.
Kernel debug (fw ctl zdebug -m fw + drop) on the intermediate Virtual System / Virtual Gateway confirms that its policy drops the encrypted responses the VPN Virtual System / VPN Virtual Gateway sends to the Remote Access Client.

Cause

In a specific topology, where the IPsec traffic flows through an intermediate Virtual System / Virtual Gateway, the security policy on that intermediate Virtual System / Virtual Gateway may drop IKE (UDP port 4500) or encrypted packets, because by the current design the intermediate Virtual System / Virtual Gateway does not synchronize the encrypted connection to all Security Group Members. It only synchronizes with the Security Group Members that have the connection entry of the IPsec tunnel.

Solution

This problem was fixed. The fix is included in:

Jumbo Hotfix Accumulator for R82 starting from Take 14

If you choose not to upgrade, Check Point can supply a Hotfix. Contact Check Point Support to get a Hotfix for this issue.

A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix.

For faster resolution and verification, please collect CPinfo files from the Security Management Server and Security Gateways involved in the case.

Hotfix installation instructions:

Refer to sk168597 - How to install a Hotfix.

Workflow

Install the Hotfix on the Security Group.

Refer to sk168597 - How to install a Hotfix.

Configure the IDs of the intermediate Virtual Systems / Virtual Gateways as values of the kernel parameter "vses_sync_passing_vpn_conns".

The kernel parameter accepts comma-separated integers from 0 to 512 - the IDs of intermediate Virtual System / Virtual Gateways.

Each listed intermediate Virtual System / Virtual Gateway will synchronize all IPsec connections (identified as ESP protocol or UDP-encapsulated ESP) to all Security Group Members.

To configure this kernel parameter on a Scalable Platform Security Group, run in Gaia gClish:

   fw ctl set -f str vses_sync_passing_vpn_conns 'VSID1,VSID2,...,VSIDn'

Example for VS1 and VS3:

fw ctl set -f str vses_sync_passing_vpn_conns '1,3'

NOTE

This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.

Article Properties

Access Level: General

Status: Approved by TAC

Date Created: 2025-01-21

Last Modified: 2025-04-20