In my past life, I did a heck of a lot with Check Point FireWall-1, now called VPN-1 Power or something. I don't do much with it now except for use their VPN client to access work, but I do spend some of my day job reviewing stuff other people write about it.
One of the things I have to do in order to use my work computer on my home network is to actually allow my work computer to access a couple of things at home: namely my Mac sitting right next to it and my network printer. Unfortunately, the combination of the VPN configuration and the firewall software loaded on the laptop make this a challenge, but not difficult.
One of the things the VPN does is add all these routes to the routing table that essentially override the local routes. Now I can see why an enterprise might want to do that, but if you want to access local resources, then it creates a challenge.
What I was doing to correct this issue was doing all this by hand: looking at the routing table, removing the offending routes, and adding a few others. In smaller environments, the routes are going to always be to the same default IP. The problem with the implementation I am working with is the nexthop for these routes has a habit of being different each time I connect. I needed to look at the routing table manually before doing the surgery on it. The end result was that I could access the machines I needed.
Today, I got the bug to automate all this, so I decided to write a Windows Batch file to accomplish all this. Apparently, this was harder than I thought, but I wrote a batch file that:
- Looked at the routing table for a route I know the VPN will set. Fortunately Windows allows you to print only a specific route.
- Parse out all the junk that gets printed in addition to the information I wanted. This parsing turned out to be the most difficult, particularly in getting the information out of a FOR loop.
- Set routes, which is relatively easy once you have the information.
And FTW, I decided to also add in automatically logging into SecureClient. One batch script logs me in and mucks with the routing table. To find that information, I had to refer to a tome I wrote nearly four years ago
. Yes, I know it was published in 2004, but I did a lot of the writing for it in 2002/2003. Damn publisher lead times. Anyway, I looked in a more recent Check Point book (on NGX) that I had lying around and it didn't even cover SecureClient on the command line. It's not the first time I found something in my own book that hasn't made it into other, more recent books, either.
Anyway, I am happy to say it's all working just fine. I do miss being able to use my SecureClient GUI (enabling CLI mode disables all that stuff), but I like how much easier the entire logging on experience is now. For those who are interested, I am posting my batch job after the break. If you're interested, click on thru and read my handy work.
@REM kill Echo
@echo off
setlocal EnableDelayedExpansion
set SCC="C:Program FilesCheckPointSecuRemotebinscc"
%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)
)
: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
