CheckPoint VPN client fails if host have too many IPs

[i3v]

I have "Endpoint Security VPN" client_ver (E88.40) client_build_number (986105609) installed on my laptop.
It provides "Ethernet 3" (Check Point Virtual Network Adapter For Endpoint VPN Client) adapter to the corporate LAN.
It connects to the Internet via an "Ethernet" (physical) adapter.

I also have "Microsoft KM-TEST Loopback Adapter" (see method2). Before you ask why I need it:

• I need it to perform TCP tunnelling via ssh, like this: 

ssh -o ExitOnForwardFailure=yes -N   -L 192.168.201.1:22:10.138.1.1:22  -L 192.168.202.1:22:10.138.2.1:22 user@sshgateway

• That is, the KM-TEST adapter got multiple IPs assigned to it (one per remote target ip):

$gateway = "0.0.0.0"
$mask = "255.255.252.0"
netsh interface ipv4 set address $pp.local_adapter_name static $first_ip $mask $gateway
foreach ($node in $pp.remote_nodes){
	netsh interface ipv4 add address $pp.local_adapter_name $node.local_ip $mask $gateway
}
# just-in-case:
netsh interface ipv4 set interface $pp.local_adapter_name metric=9990

• I'm unable to use a single IP and a multitude of ports to access all those remote nodes. Because one app I need does not allow to explicitly specify ports.

This setup worked OK, in general, with 122 IPs assigned to the "KM-TEST Loopback Adapter" for a few months already.
Today I've tried to add 20 more IPs, and suddenly CheckPoint VPN got broken - stuck in a reconnect loop saying "Connectivity with the Check Point Endpoint Security service is lost".

• Even though CheckPoint fails, other apps seem to work OK - e.g. I'm still able to use Chrome web browser and etc.
• CheckPoint VPN starts to work again as soon as I reduce the number of IPs (assigned to the "KM-TEST Loopback Adapter" adapter) to 128. Fails with 129. Specific IPs do no matter - removing either "new" or "old" ones fixes CheckPoint.
• To my best knowledge, these "192.168.200.0/22" IPs should not conflict with anything.

So... It looks like CheckPoint VPN client breaks if there are >128 IPs on some network adapter in the system. Even though CheckPoint  should actually just completely ignore this adapter.

Could you please suggest any fix/workaround?

[the_rock]

I dont know if thats indeed some sort of limitation or not, but seems like you already had done lots of testing/trounleshooting yourself, so I would definitely open TAC case at this point.

Andy

[PhoneBoy]

We use a kernel driver to redirect traffic to the correct interface.
That means all interfaces are relevant.
A TAC case is in order, but I suspect this might be an RFE.

[i3v]

Just in case anyone would also run into this:

I've contacted IT, they contacted a support representative, they contacted CheckPoint R&D. 
I've demonstrated the issue during a live session and provided a script to reproduce the issue.

Here's their reply:

After reviewing the issue with R&D, we have a better understanding of the behavior observed during the VPN connection.
When the VPN reconnects, the client installs the required network routes and synchronizes the Windows Firewall configuration. These operations are performed synchronously during the connection process. As the number of IP addresses configured on the system increases, this process takes longer because part of the route installation checks every route against every available IP address.
In this environment, the additional virtual network adapter significantly increased the number of IP addresses on the system. Once the processing time exceeded the internal timeout, the VPN service watchdog assumed the service was no longer responding and automatically restarted it while the route installation was still in progress.
After the service restarted, it attempted to roll back the partially installed routes. However, the rollback process is designed to stop if it encounters an unexpected condition, such as a route or interface that has already been removed. As a result, the rollback could not complete successfully, leaving some routes in the Windows routing table.
Based on R&D's analysis, this is considered a product limitation rather than a software defect. The current implementation was not designed to handle environments with such a large number of IP addresses on an additional network adapter or to recover gracefully if the service restarts during the route installation process. Since this type of environment is uncommon, this limitation had not previously been encountered.
Please let us know if you have any questions.

---

I've also asked:

Well, personally, I really doubt that a timeout could be the root cause - the issue is way too reproducible (100% works with exactly 136 IPs in the system, and 100% fails with 137 IPs in the system).

---

And they replied:

I understand your point. However, based on R&D's analysis, there is no fixed limit in the client code for the number of IP addresses. Although the issue consistently appeared at around 136–137 IP addresses during our testing, this is not a hard-coded threshold. It simply reflects the point where the route installation and firewall synchronization took long enough for the VPN service watchdog to consider the process unresponsive and restart the service. Depending on the environment, this number could be different

---

Personally, I still doubt that this could be a "timeout". Even if there's no explicit hardcoded limit, there could be an implicit one.

TLDR: they acknowledged that the issue/limitation exists. They are not going to fix it.