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.