Checkpoint firewalls have 3 means of  transferring files in/out – ftp (client ) , SCP and SFTP (haven’t tried it yet) .
At some stage of the debug/upgrade process you will have to move files in either direction. The most secure is SCP protocol. On windows platforms picking the GUI SCP client is not hard – you only have WinSCP as your choice. And being otherwise  reliable and easy to use software it just doesn’t work with Checkpoint many times.  To fix this is easier than you can think of.

But first few prerequisites:

  To allow SCP connection to the firewall you have to :

       – create file named /etc/scpusers

       – add to it user per line – with which user you will be connecting for SCP session

       – make sure that for this user(s) shell is set to /bin/bash in /etc/passwd file

       – and of course allow SSH protocol connection from your host to the firewall.

After all the above done you connect using WinSCP, all goes well, try to download some file and …

Error happens…
The easiest way (and the only one I found so far ) is to .. NOT use WinSCP but instead use wonderful
software PSCP from Putty author that doesn’t have GUI but works flawlessly with Checkpoint.
Download it here www.chiark.greenend.org.uk/~sgtatham , read instructions and have no regrets ever after.

Log is knowledge (of who did what) and knowledge is power. All modern Operating Sytems today provide extensive logging facilities, and Linux on which Checkpoint products are based is no exception.
Checkpoint have own logging capabilities where logs are enabled in Security rulebase. And that’s fine, but SSHD daemon also has  logging and rotating feature which by default is limited to retain only last 4 logfiles.
I found it very useful to have ssh access logs for a longer period, especially when client also has access to the firewall and does changes on his/her own.
To tune parameters of the SSH logging edit /etc/cpshell/log_rotation.conf (no need to restart anything) :

# cat /etc/cpshell/log_rotation.conf
# File    max  size    backlog
# By default max size is 65536 bytes and backlog (how many files to rtain) is 4, I usually change it to the values before:
/var/log/messages 65536 256
/var/log/routing_messages 64536 256
/var/log/wtmp 65536 256
/var/log/lastlog 262400 256
/var/log/secure 64536 256
$CPDIR/log/cpstart.log 1048576 4
# Files after this line will not be shown by log command
/var/log/CPbackup.elg 64536 4
/var/CPbackup/log/backup_logs.elg 64536 4
$FWDIR/log/fwd.elg 1048576 4
$FWDIR/log/dtlsd.elg 1048576 4

< CUT here —————————– >

This is a quick reference sheet of all usable options for the fw monitor tool .At the end I put a list of fw monitor examples. The previous experience with the tool is assumed, i’ll just say that if you are serious about debugging Checkpoint products learn it and learn it well.
By default the fw monitor sniffing driver is inserted into the 4 locations on
the Firewall kernel chain .
Here they are:

 i (PREIN) – inbound direction before firewall Virtual
Machine (VM, and it is CP terminology) . Most important fact to know about that
is that this packet capturing location shows packets BEFORE any security rule
in the policy is applied. That is, no matter what rules say a packet should at
least be seen here, this would prove that packets actually reach the firewall
at all.
 I (POSTIN) – inbound direction after firewall VM.
 o (PREOUT) – outbound direction before firewall VM,
 O (POSTOUT) – outbound direction after firewall VM.

You can change point of insertion within the fw chain with :

# fw monitor –p<i|I|O|o> <where to
insert>

easiest way to specify where to insert is to first see the chain:
# fw ctl chain
then give relative to any module you see there <+|->module_name

Now the usage itself:

Round up of options:

-m mask , which point of capture is to be displayed, possible: i,I,o,O
-d/-D debug output from fw monitor itself, not very useful IMO.
-u|s print also connection/session Universal ID
– i after writing each packet flush stdout
-T add timestamp, not interesting
-e expr expression to filter the packets (in detail later)
-f filter_file the same as above but read expression from file
-l <len> packet length to capture

Expressions
On the very low level fw monitor understands byte offsets from the header
start. So to specify for example 20th byte of the IP packet (that is source IP)
you can just use:

# fw monitor -e 'accept [12,b]=8.8.8.8;'

Where:
12 – offset in bytes from the beginning of the packet
b – mandatory, means big endian order.
4 – not seen here but size (in bytes) of how many bytes to look for from the
starting offset (default is 4 )

To look for source port 53 (UDP/TCP) in raw packet:

# fw monitor -m i -e 'accept [20:2,b]=53;'
Here I say to fw monitor to look at 2 bytes at offset 20.

While this way of looking at packets is the most general and therefore includes
all cases, you rarely have the need for such a granular looking glass. In 99%
of the cases you will be doing alright with a limited known set of expressions.
Just for that Checkpoint defined and kindly provided us in every Splat
installation with definition files that give meaningful synonyms to the most
used patterns. There are few definition files but they circularly reference
each other providing multiple synonyms for the same pattern.
I put all those predefined patterns in the list below for the easy to use
reference.

and – logical AND
or – logical OR
not – logical NOT
> MORE than
< LESS than
>= MORE than or EQUAL to
<= LESS than or EQUAL to
You can combine logical expressions and influence order by using ()

Below is laundry list of examples to showcase the reference table above.

Resources:
PDF version of fw monitor command reference

 Sometimes machines fail , in the end all machines fail some day anyway. When it happens to the firewall (Checkpoint ) it might be a very
frustrating event . By failing I mean machine turns on but doesn’t boot or boots into unusable state. The first thought that comes to
the sysadmin looking at such a miserable piece of expensive metal – format/fdisk/Factory Defaults/anything !!!???
If you have Checkpoint Open Server (i.e. Checkpoint VPN-1 software installed on 3rd party server) then most probably you have CD/DVD-drive in it and what  left is to find installation CD  of the Checkpoint – 30 minutes, some basic rules and your network partially but starts to work.
But if you have a Checkpoint UTM  appliance you have a problem. A big one. There is no magic button to restore to factory defaults nor CD/DVD drive to start formatting/reinstalling the firewall immediately.  Not that Checkpoint didn’t think about that situation, just reinstalling/reimaging  procedure is a bit involved.
I won’t say new things here as all is neatly documented in SecureKnowledgebase of checkpoint.com (sk37231) . But as I get questions about that more frequently than people bother to check at the Checkpoint website here is a short procedure:

– You download from checkpoint.com (with download speeds and image size patience is your friend) UTM image matching your UTM version ;
– You burn it to DVD disk (It is 1,5 Gigabyte in size) ;
– You connect USB DVD drive to USB port in UTM reboot from it and start install from scratch.

That is it.

PS If you happen to forget SSH password of the expert user you are also left with grim option to try to boot appliance from some bootable DVD and reset password, or just plain reinstall the whole firewall. So be very careful about SSH passwords for the UTM appliances.