The PhoneBoy Blog

Fun With SPLAT, VMware, and IPSO

26 Feb 2009

Seeing as how I have my Check Point CCSE again, and it’s likely I’m going to be working for Check Point at some point in the near future, I figure it’d be worth my while to get a “proper” Nokia firewall going again. I opted for the following:

• NGX R65 HFA_40 SmartCenter on Secure Platform (SPLAT) installed in a VMware VM
• NGX R62 HFA_01 firewall installed on a Nokia IP260

Yes, I realize that R62 is going EOL in May. However, the IP260 is by far the quietest machine I have around here, and if I’m going to have it on all the time, I want it quiet. That’s another reason I went with a management station in a VM: the machine the VM runs on is relatively quiet.

To frame my experience properly, it’s probably worth reiterating some facts:

• At some point in my life, I was considered an expert on the Check Point VPN-1 product. Maintaining an FAQ and writing two books on the product gives people that impression, even today
• The last time I did anything serious with Check Point was back in the NG AI days, which is about where my second Check Point Firewall-1 book goes up to. In other words, roughly 5 years ago.
• I currently maintain the knowledge base for Nokia’s Security Appliance Business which, unsurprisingly, has a lot of Check Point-related stuff in it. Yes, I read a lot of stuff about the product even though I haven’t got a lot of recent, practical experience with the product.
• I have never, prior to the CPUG University class I took recently, even seen SPLAT, much less installed it on anything.

With these facts in mind, I created a blank VM and loaded up the SPLAT ISO. How hard can it be, I figure?

The initial load of SPLAT went ok, as did the initial configuration. However, compared to the newsystem script on IPSO, which runs during the initial configuration of a Nokia Appliance, the SPLAT sysconfig script is much more painful, just based on the number of keystrokes. To be fair, sysconfig lets you configure a few more things, but newsystem really focuses on getting you out of the initial configuration mode and on your way to either Voyager or clish to do the real configuration. In my mind, that’s a better way to go.

After I fetched licenses, installed them, and loaded HFA_40 into the SmartUpdate repository, I tried installing HFA_40 on the SPLAT box. No go. Can’t use SmartUpdate on yourself (duh) so off to install the HFA manually. A quick perusal of the release notes suggests I can install this via the SPLAT webui, which is analogous to Voyager on a Nokia box. In other words, a web-based configuration tool.

The first time I tried accessing the webui using Firefox 3.0, I was unceremoniously informed that I needed to disable popup blocking and prevented from logging in. After fixing that problem, I tried again. This time, I got a popup dialog that said:

Cannot connect to server. Make sure the device is up and running, and that you are allowed to login from this machine.

When I pressed Ok, I was presented with the WebUI login screen. Despite the fact I can log in via console and SSH ok, all users on the webui give me the following error:

Cannot login. Make sure the device is up and running, and that you are allowed to login from this machine.

A co-worker who spends way more time talking with Check Point Support than I do got a few techs on IM. They were scratching their heads. One of them eventually suggested I try a different browser, which sure enough worked. The latest version of Check Point shipping wasn’t tested on the latest Firefox? Clearly not! Nokia KB article written–first Check Point one I’ve authored in quite some time

Now, to install HFA_40. Since I already loaded the HFA into the SmartUpdate repository, I figure it has to be somewhere on the SPLAT box. Found it somewhere in /var/suroot, unpacked, installed, rebooted, and we’re on HFA_40. And the webui still doesn’t work with Firefox 3.0.

Meanwhile, installing SmartConsole NGX R65.4 (HFA_40) and expecting it to manage NGX R65 without HFA_40 installed was clearly faulty thinking on my part. Then again, how hard would it be to make this work on the development side? Seems like I need to install both sets of clients on my system to manage this box. With SmartDashboard up, I started creating my network objects and security policy.

Once I did that, I hooked up my IP260, which came fresh from the repair center. The nice thing about this is that it had all the base Check Point packages loaded and ready for activation in Voyager. Enable a couple of packages, and now off to cpconfig. A couple of questions:

• I know that IPSO has a proper pseudo-random number generator that gathers entropy from all the proper sources. We use it in our now defunct SSL VPN product. Why is it that I still have to feed Check Point VPN-1 a series of keystrokes for entropy when on every other platform, Check Point VPN-1 no longer asks this?
• How come we get asks the OS groups question on IPSO? This has no effect on IPSO and can’t be used. Why is this still a question?

VPN-1 is enabled on the IP260, SIC established, policy pushed, etc. Pushed R62 HFA_01 through SmartUpdate to the Nokia Appliance, worked like a charm. Other usual Check Point configuration from there.

One other thing. Not sure what caused it, but I noticed that my SmartCenter was loading a security policy! I poke around in the Check Point registry and determine yes, it did believe it was a firewall for some reason. Hack the registry, write another Nokia KB article, cprestart, and while the module doesn’t believe it’s a firewall any longer, it is still loading a default filter! One control_bootsec -r and a reboot later, the module was back to normal!

Needless to say, that took way longer than it should have. However, one thing I’ve learned over the years is that it is in those difficult times that you learn stuff, which in my case means a new KB article or two and possibly a blog posting