FireWall-1 FAQ: fw ctl pstat output in FireWall-1 4.1
Please note: This content was from when I was operating my FireWall-1 FAQ site, which I stopped operating in August 2005. For some reason people still have links to this stuff on the Internet that people are still clicking on.
I am making this information available again AS IS. Given how old this information is, it is likely wildly inaccurate. I have no plans to update this information.
If you're still running versions of Check Point VPN-1/FireWall-1 where this information is still relevant to you, do yourself a favor and upgrade to a more recent release. If you happen to be running a current release and the information is useful, it's by happenstance :)
A normal fw ctl pstat command outputs something like this:
Memory: 3145728 bytes, 3128696 avail, Requests: 1960086 alloc, 1959806 free, 0 reject
Inspct: 106159458 packets, 1540579670 operations, 395618400 lookups, 6544675 record, -1888737107 extract
Cookies: 106371582 total, 182800 alloc, 182800 free, 238 dup, 272447125 get, 430 put, 212320128 len
Fragments: 272 fragments, 0 expired, 100 packets
Encryption: 0 encryption, 0 decryption, 0 short, 0 failures
Translation: 12314763/23596384 forw, 13011800/23786409 bckw, 25222778 tcpudp, 103785 icmp, 519546-487730 alloc
The first line is the most immediately useful piece of information we can get: how much memory FireWall-1 has available in its kernel tables, which are primarily used to track the state of connections as they pass through the firewall. A fixed amount of memory is set aside for this purpose. The amount of memory allocated is controlled by the fwhmem kernel parameter (see halloc: unable to allocate 68 bytes for how to modify this). For performance reasons, this memory is hard-wired (i.e. it can not be swapped out), so it is important that this value is as low as possible so as not to starve the user-level processes of FireWall-1. In the above example, 3,145,728 bytes (or 3 megabytes) have been allocated into FireWall-1’s kernel memory pool, of which 3,128,696 bytes are still available. he number of memory allocations that can be made against this kernel memory pool (at once) is 1,960,086, of which 1,959,806 are currently not being used. No memory allocations have been rejected due to memory exhaustion.
The second like gives the number of operations that the stateful inspection engine has performed. For busy firewalls that have been functional for several days, it is not unusual to see a negative number in any one of these fields. This indicates the counter has “rolled over”.
The third line talks about cookies. No, not the kind your mother or a web site might give you, but an abstract data type that FireWall-1 uses to represent packets. These statistics are only meaningful to the developers.
The fourth line gives statistics on packet fragments that FireWall-1 has received. In order for FireWall-1 to properly enforce the security policy, it must reassemble any packet fragments it receives. Note that once FireWall-1 has performed the reassembly and it determines the packet should pass the security policy, the packet fragments are send out as they were received. In the above example, 272 fragments were received and assembled to 100 packets. Packet fragments that can not be reassembled within 20 seconds are considered expired and we have not seen any expired packet fragments.
The fifth line gives encryption statistics, i.e. how many packets FireWall-1 has encrypted and decrypted. Short packets refer to the number of header-only packets the FWZ encryption scheme has had to process (FWZ only encrypts the data portion of the packets).
The last line gives statistics on Network Address Translation. Of the 23,596,384 packets going “forw” (outbound), 12,314,763 packets were translated. Of the 23,786,409 packets coming “bckw” (inbound), 13,011,800 were translated. 22,222,778 of these translations were for tcp and udp packets and 103,785 were ICMP. 519,546 tcp/udp port numbers were allocated for translations while 487,730 were deallocated.
