PhoneBoy’s Security Theater

When I was at the car dealer yesterday giving my car some service love, I hung out at the dealership while the repair was taking place. My dealer is pretty good--they give you a coupon (or two) for a free latte while you wait for your car to be serviced. They offer WiFi throughout their waiting area. They also have a "lounge" where you can either use one of the computers they have or use your own.

Despite the dealer having WiFi, I didn't use it. Why? Their system requires reauthenticating every two hours, which gets old when I know I am going to be there for at least twice that long. Instead, I decided to use my Sprint EVDO dongle.

Unfortunately, I spent a long time fighting with the Sprint Connection Manager software (version 1.10.0023.0) instead of working. When I tried to use it to connect, then started up my VPN to connect to the office, my EVDO connection would unceremoniously disconnect. I don't remember my Verizon card ever doing this.

I eventually figured out how to get this combination working. The hint is in the graphic here. Sprint's software--and presumably Verizon's software--are simply front ends for the standard Windows dial-up networking. Sprint's software also has this NDIS mode in it--make sure it's set to RAS before you do this trick.

In Check Point Secure Client (which us old-timers still call SecuRemote), I told it to use a Dial-up connection, which shows up in the Connection window. In my case, I ticked the Use Dial-up option and used the connection called CDMA. There was another one called 3G Connection that I didn't try. After this, Secure Client properly brought up the EVDO connection and started my VPN. The connection didn't drop once and worked reliably for the rest of the time I was at the dealer.

I left the Sprint Connection Manager software running, but I don't believe it was necessary. It continued to show me signal strength and the like, but I did not see any details about how much data I was sending and receiving. That's ok, just as long as my EVDO worked.

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