Fun with Check Point SecureClient and Windows Batch Files

Reading time ~4 minutes

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
Reblog this post with Zemanta

A Couple Decades (And Change) of Working From Home

When the Covid-19 pandemic was declared in March of 2020 and most everyhigh-tech business became "all remote all the time" literally over...… Continue reading

Some Things Never Change at Palo Alto Networks

Published on October 20, 2020

My Two Check Point Decades

Published on February 01, 2019