You are always going to have a bad time if your local client is using an IP address that is also used by the remote VPN.
I had a similar problem years ago when the VPN was preventing me from using my local LAN.
I ended up writing a batch file to solve the problem, which, with some modifications, may be useful.
Note that this also starts up SecuRemote in CLI mode, which may not work or be relevant anymore.
From https://phoneboy.com/1405/fun-with-check-point-secureclient-and-windows-batch-files:
@REM kill Echo @echo off setlocal EnableDelayedExpansion
set SCC="C:Program Files\\CheckPoint\\SecuRemote\\bin\\scc"
%SCC% setmode cli
rem %SCC% disconnect
%SCC% up username %1%
%SCC% connect "VPN Profile"
%SCC% status
%SCC% ep
@REM Trying to pull out VPN route and mess with routing table
@REM
@REM Did we find the netmask line?
set hitnetmask=0
@REM Let's pull out a route I know will be there:
@for /f "tokens=3" %%i in ('route print 192.168.0.0') do (
@REM After we found the netmask, the next thing we get is the route we want
@REM and make sure we get out of dodge
if !hitnetmask! EQU 1 (
call :set_nexthop %%i
GOTO :found_route
)
@REM The next line after the "netmask" line is the one we want.
if "%%i" == "Netmask" (call :set_hitnetmask)
@REM end for
)
:set_hitnetmask
set hitnetmask=1
GOTO :EOF
:set_nexthop
set nexthop=%1
GOTO :EOF
:found_route
echo Nexthop is %nexthop%, deleting/setting the routes appropriately
echo on
route delete 192.168.0.0 mask 255.255.255.0 %nexthop%
route delete 192.168.0.2 %nexthop%
route delete 192.168.2.253 %nexthop%
route add 192.168.2.253 192.168.0.254
@endlocal