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