Q: How do I monitor firewall activity on the firewall itself?

A:

Use the fw monitor tool at the Nokia command line. Here are some examples:

fw monitor -e 'accept src=192.168.152.121 or dst=102.168.152.121;' -o filename

fw ctl zdebug + drop > filename2

Make sure to open multiple command line sessions to the firewall/s to run both the fw monitor and fw ctl zdebug commands at the same time. Also, the fw log export must be taken at the same time.

Q: How do I use the cprules utility to document my Checkpoint ruleset?

A:

The free cprules utility can read your data files from your management server and produce HTML output. Here's how:

1. Log onto your management server and find the conf directory that contains objects_5_0.C and rulebases_5_0.fws.
2. FTP or SCP these files down to the PC which has cprules installed.
3. On the management box, run these two commands:

   fwm dbexport -f users.exp
   fwm dbexport -g -f groups.exp
   

4. Copy the users.exp and groups.exp files to your PC as well.
5. On the PC, run perl CPusers.pl. This will create users.C
6. For each ruleset in your database for which you want a report, run perl CPrules.pl --rulebase {rulesetname}. This will create a subdirectory called rulesetname containing the output.

Q: Where are Checkpoint state table timeouts logged?

A:

To troubleshoot why TCP packets are getting dropped due to out-of-state (o-o-s) way before it seems they should according to the "service" settings, I need to look at the log of state table changes.

It seems that the table can be dumped as ASCII by logging onto the firewall and issuing this command: fw tab -t connections -max 1000. In this example I used 1000 for the max; if this is not enough, you will see "more..." at the end of the table. Note that the table produced, although text, is not really human-readable.

Q: How do I tell how much RAM I have in my Nokia box?

A:

Use the cli command dmesg.

Q: I want to change the patching of one of my cluster interfaces without making the Nokias join and unjoin the cluster. How do I do this?

A:

We're asumming here you have two or more Nokias, each with an interface going to the same hub or swtich and want to work on the switch or repatch to a new switch. Whenever a Nokia detects a loss of link on any cluster interface, the whole Nokia leaves the cluster. This can cause undesirable connection drops on other cluster interfaces (even though it's not supposed to). UPDATE! Here's an elegant solution, so obvious I didn't see it: before doing the repatching, turn off power on all cluster members but one. Repatch everything before powering the other cluster members back up. That being said, here's the earlier, not-so-elegant solution: The only solution is to take the interfaces to that switch out of the cluster until the work is completed. Note that while doing this, the Nokia will leave and rejoin the cluster, but after that it should stay put. Here's how:

1. Make a note of the cluster IP (and MAC) and the individual IPs of the interface you are working on (lets call it eth2).
2. Log on to firewall 2 Voyage as admin (not cadmin). Go to config/clustering setup.
3. If eth2 is a cluster interface, you'll see "yes" in the select column next to eth2c0. Change this to "no".
4. Apply and save and see what happens. I think the node will leave and rejoin the cluster, and the segment on eth2 will still be up on the other Nokia.
5. Log out of firewall2 and log into firewall1, as admin.
6. Take this firewall's eth2 out of the cluster in the same way, apply and save. The node should leave and rejoin again. The hosts on your segment will be unreachable because the cluster IP will be gone.
7. On firewall1, change the IP of the local eth1 to the former cluster IP. Now the segment should be reachable again.

Q: What do the choices under the firewall object's "Connection Persistence" dialog mean?

A:

The "connection persistence" settings define how the firewall treats established connections when installing a new policy.

• Keep all connections: Keeps all control and data connections open until the connection has ended. The newly installed Policy will be enforced on new connections only.
• Keep data connections: Keeps all data connections open until the connection has ended. Control connections that are not allowed under the new policy will be terminated.
• Rematch connections: This means that all connections not allowed under the new Policy will be terminated.

Additionally and separately, each service has its own checkbox titled "Keep connections open after policy install", normally not checked. If checked, this service's connections survive a policy install as if "keep all connections" were the global policy, regardless of what the global policy actually is. Therefore, this checkbox overrides the global policy setting.

Q: If I set up a static address translation in one direction, do I need to create a matching rule for the other direction?

A:

On the address translation tab of the firewall policy, if I set up a static translation in one direction, do I need to create a matching rule to translate the return traffic back? If not, why do the "automatic" address translation rules do this? In other words: Rule #1: OrigSrc=any OrigDst=mywebserver public OrigPort=any XlatSrc=original XlatDst=mywebserver private XlatPort=original Must we create this second rule, as the automatic rules do? Rule #2 OrigSrc=mywebserver private OrigDst=any OrigPort=any XlatSrc=mywebserver public XlatDst=original XlatPort=original Seems to work fine without rule #2. So why do the automatic rules do this? working on it...

Q: How do I keep the firewall's SmartDefense from dropping some of my FTP sessions?

A:

The firewall log says some of the FTP sessions are being dropped for "reason: tried to open a known service port". This is a case of the firewall trying to be just a little too clever. It's dropping any FTP sessions from an ephemeral port that happens to be defined as a service port (or part of a range of service ports) in the rulebase, on the off chance that the session is an FTP bounce attack and not part of an actual FTP session. To stop this from occurring, go to the SmartDefense tab in the management console. Navigate to leaf object "Network Security / Dynamic Ports". You can leave "Block data connections to low ports" checked, but choose the radio button for "Allow data connections to all defined services' ports". (Of course, this won't take effect until you install the policy.) This solved the problem for me. I would have thought that the SmartDefense "Application Intelligence / FTP / Prevent known ports checking" would have been the thing to check, but that is still unchecked and the FTP sessions are working.

Q: Whats all the brouhaha about turning off ifwd on the Nokias?

A:

ifwd is a daemon that runs on the IPSO platforms. "fwd monitors interface changes and resets firewall processes if an interface changes state"; more info at resolution 20521: ifwd is generally recommended to be disabled in NG AI. In Check Point VPN-1/FireWall-1 NG AI, Nokia recommends turning off this daemon (follow above link to see the entire suggestion.) Resolution 1280 talks further about the use of ifwd. It states that ifwd should be started before adding or changing interfaces, and then stopped after the changes are made. To start or stop ifwd, log into Voyager, and look for Config/Security/Checkpoint. There's a radio button to start and stop ifwd in there.

Q: How do I check if state sync is working between the firewalls?

A:

Used to be able to use netstat -an on previous versions of FW-1; this no longer works. Those older versions used TCP to synchronize the connections table; newer versions use a custom UDP-like L2 protocol. cphaprob state is supposed to give the status of the HA config. However, according to Nokia, it is more reliable to execute fw tab -t connections -s on each firewall, then compare the value for #VALS (which is the number of entries in the connection table). They should be close.