Extending logging partition on your management station

One of the major challenges when managing Check Point security systems is about log storage. If you are not careful and/or proactive, you can run out space eventually.

It does not matter, how much free space you plan for your logging partition, one day it may not be enough. If this day comes, what are you going to do?

Of course, you can always delete some old logs or just get a bigger box. If latter, then you have to run through a long migration procedure.

What about adding a new storage? There is a way to change Gaia partitioning with LVM management tool, as described in SK95566.

There is even an article about extending logging partition to a new disk drive. Take a look on SK94671. It describes VMware case, but can be in general applicable to any additional HD.

CPUG 2015 - let's make it happen

Do you miss annual CPUG conference? I do. Today, with the new owner of CPUG.org, it is time to plan it again.

We as CPUG community shell make it happen. Here are some questions for you, please take a minute to respond:

1. Did you participate in CPUGcon in the past? Are you going to participate in  CPUGcon 2015? If yes, will you invite and encourage to participate you colleagues, friends, clients and partners?
2. What would be ideal location for you? Mind we are talking about European event.
3. Could you help CPUG to find the best suitable location? We would like to accommodate around 80-100 people. We might need one or two conference rooms, with some reasonable priced hotels around and not too far from an airport. Any thoughts?

All, please feel free to share your opinions and suggestions. 

Static routes issue with R75.47 on 13500 appliances

I am in the middle of preparing FW migration for one of my favourite customers, who wants to replace open servers with 13500 to benefit multi 10GB connectivity.

One unexpected thing on the way was configuring new static routes on these appliances after clean installation of R75.47. I have tried both CLISH and WebUI, but routes were not in effect. I could see routes in the WebUI but not on clish with "show routes" and not on expert with "netstat -rn". It was like routes were never making it to IP stack. I have seen that on early Gaia versions, but on R75.47 it seems impossible, right?

It took some time to triple-check all the settings. It was all properly configured, except for a default GW that was never  defined. I have punched it in, still unable to see any static routes defined on OS level.

Only after installing a driver fix from sk99113 and consecutive reboot all static routes start appearing and working.

I have checked this situation on the second appliance. Strangely, static routes were not appearing even after drivers installed, if default GW was not defined.

So to configure static routes properly on 13500 running R75.47, one has to have two things done:

1. Drivers from sk99113

2. Default route in place

The only explanation I have for the matter is that 13500 with R75.47 was never a part of QA cycle. 

R77.20 gateway forward compatibility, SIC!

Something revolutionary is happening with Check Point releases lately. For example, it was never supported to have a Firewall software version higher that Management server's one.

Now it is no longer an issue. Quoting from R77.20 release notes:

CPUG is back to life

Great news for the community: CPUG is back to life. Read by the link if you are interested to know the details.

Thanks to Netanium and Eric Anderson for their efforts.

CPUG will be back, as we all hope

Hello, world.

I do not want to be too optimistic, but according to some sources, CPUG will be back very soon. No more details are available for now.

Setting proxy ARP for bonded interface

One of the interesting challenges is about setting proxy ARP on a FW  bond interface to facilitate manual NAT rules.

There is a very good SK article about proxy ARP configuration that covers both physical firewalls and VSX. There is only one problem with that: it is not applicable to bond interfaces. HA or LS bond type, does not matter. The main issue is that one cannot use either MAC address of the NICs in bond, as frames may sometimes go through another physical link.

So is it absolutely impossible to use a combination of proxy ARP, manual NAT rules and bond interfaces?

Not exactly. Here are several steps that you need to do.

1. Set up VSX and not a physical FW. Even if you do not have VSX licenses, physical FW license will allow you to run a single Virtual System. That is all you need.
2. Instead of connecting your bond interface to the Virtual System (VS), define a Virtual Switch (license will also allow that) and connect it to the bond.
3. Create a virtual link (warp) between VS and the Virtual Switch.
4. Go to CLI, check MAC address of the warp link and use it in local.arp file. Do not forget, you have to set unique ARP entries for each cluster member.

Problem solved.