Checkpoint - some commands

To change default shell for admin account to bash and allow WinSCP connections,
   chsh -s /bin/bash admin

To return the setting back to default shell,
   chsh -s /etc/cli.sh admin

--------------------------------------------------

fw stat  -- run on gateway
fw unloadlocal   -- run on gateway to uninstall the firewall policy
fw fetch localhost -- run on gateway

fwm load Standard A-GW-01 --on management server

cpinfo
cpinfo -o <output file name>.txt
fw ctl pstat --monitor health and sync status on GW

fw monitor
fw monitor -e "accept src=10.1.1.201 or dst=10.1.1.201;" -o monitor2.out

Checkpoint - fw ctl pstat

Only run on Security gateway.

monitor the heath of your CP box., especially Syc Status.

Sync:
Version: new
Status: Able to Send/Receive sync packets
Sync packets sent:
total : 466729198, retransmitted : 241305, retrans reqs : 6089, acks : 809
Sync packets received:
total : 77283541, were queued : 6715, dropped by net : 6079
retrans reqs : 37462, received 175 acks
retrans reqs for illegal seq : 0
dropped updates as a result of sync overload: 0
Delta Sync memory usage: currently using XX KB mem
Callback statistics: handled 138 cb, average delay : 2, max delay : 34
Number of Pending packets currently held: 1
Packets released due to timeout: 18


Explanation:

Version: new
This line must appear if synchronization is configured (versions above 4.1)

Status: Able to Send/Receive sync packets
If sync is unable to either send or receive packets, there is a problem

Sync packets sent:
total : 466729198, retransmitted : 241305, retrans reqs : 6089, acks : 809
TOTAL number of sync packets is non-zero and increasing
RETRANS REQS may increase under load

Sync packets received:
total : 77283541, were queued : 6715, dropped by net : 6079
QUEUED value never decreases - A non-zero value does not indicate a problem
DROPPED BY NET number may indicate network congestion

The “dropped by net” counter is incremented when the cluster member receives a sync packet with a sequence number which is higher than the expected seq num. This means packets with lower seq where lost somewhere along the way, and we need to find out where.

retrans reqs : 37462, received 175 acks
RETRANS REQS growing very fast may indicate that the load is becoming too high

retrans reqs for illegal seq : 0
May indicate a sync problem

dropped updates as a result of sync overload: 0
In a heavily loaded system, the cluster member may drop synchronization updates sent from another cluster member

Delta Sync memory usage: currently using XX KB mem
This statistic only appears for a non-zero value.
It requires memory only while full sync is occurring at other times, Delta sync requires no memory

Callback statistics: handled 138 cb, average delay : 2, max delay : 34
This statistic only appears for a non-zero value.
AVERAGE DELAY should be 1-5 packets, otherwise indicates an overload of sync traffic

Number of Pending packets currently held: 1
This statistic only appears for a non-zero value.

Packets released due to timeout: 18
This statistic only appears for a non-zero value.
If the it is large (more than 100 pending packets), and the "Number of Pending packets currently held" is small, you should take action to reduce the number of pending packets.
To tackle this problem, try google "Reducing the Number of Pending Packets".

Checkpoint - tcpdump and fw monitor

What’s the difference between tcpdump and fw monitor ?

Tcpdump displays traffic coming or leaving to/from a firewall interface while fw monitor would also tell you how the packet is going through the firewall including routing and NAT decisions.

Let’s get deeper

FW MONITOR

It captures traffic at 4 important points in the firewall namely i, I, o & O. You would see them in the capture in the same sequence.
i – Preinbound, just where the packet is received on the interface. If you see only this then the packet is dropped by address spoofing or the access rule.
I – Postinbound, where the packet has gone across the incoming interface. If you don’t see the next line in capture after this at ‘o’, you could infer that it’s a routing issue.
For both i & I the interface is the incoming, where the packet enters the firewall.
o – Preoutbound, the place where the packet is received at the exit interface within the firewall. If this is the point beyond which the capture is not seen, then you may need to check NAT.
O- Postoutbound, If you see this then make you are sure that the packet has left the firewall and the ACL, route and NAT all are working as expected.

fw monitor -e "accept src=10.1.1.201 or dst=10.1.1.201;" -o monitor2.out

TCPDUMP.

It captures at position i & O of firewall monitor, and you can be sure the traffic has left the firewall. This is similar to the way captures work on a Cisco PIX/ASA.

So, which one you use ?

Consider you run tcpdump and see the incoming traffic but don’t see the traffic leaving the exit interface. You can guess it’s a routing or a NAT issue. But to make a sure shot without wasting time by looking in routes or the NAT rules you could run fw monitor and know what the issue is.