04-CCTE Guide

Check Point®
Troubleshooting and Debugging Tools

for Faster Resolution
July 16, 2006
IMPORTANT
Check Point recommends that customers stay up-to-date with the latest
service packs, HFAs and versions of security products, as they contain
security enhancements and protection against new and changing attacks.
In This Section
Mandatory Support Information page 1

FireWall Common debugging page 2
Security Server debugging page 4
VPN debugging page 5
Provider-1 debugging page 5
VPN-1 VSX debugging page 6
ClusterXL debugging page 6
Connectra debugging page 6
FireWall-1 GX debugging page 6
InterSpect debugging page 7
SNX – SSL Network Extender debugging page 7
Further Debugging – Memory Diagnostics page 8
Mandatory Support Information

The following information is the information that the Customer needs to provide Support
when opening a Support Service Request
1) Problem Description, provide a detailed description of the issue
2) Network Topology Diagram, provide a comprehensive diagram which illustrates the
described problem.
3) Execute CPINFO on the required Check Point component. To create CPINFO, execute %
cpinfo –o <Output file>
Over and above the information in the Service Request, it is recommended to do basic
debugging. The debugging commands can be found in this document.
Important Comments
• It is recommended that you complete your SR creation process before you run the
debug instructions detailed in this document. If you do not complete the SR creation
process first you may loose all the information you entered in the initial stages due to a
session timeout. Once the SR process is complete you can attach the debug output files
to the SR that you just created.
• In certain specific scenarios, the debugging commands included in this document may
need to be supplemented by more advanced debugging procedures. Advanced
procedures should be executed in conjunction with the Check Point Escalation
engineers.
• Debugging should only be performed when the described issue can be captured.
FireWall Common debugging
The following commands should be run on a Check Point gateway. The relevant flags will
vary according to the problem's essence.
Kernel debugging
Usage
% fw ctl debug -buf [buffer size]
% fw ctl debug [-x] [-m <module>] [+|-] <options | all | 0>
% fw ctl kdebug –f > <output file>
To disable the Kernel debugging, execute:

% fw ctl debug –buf 0
% fw ctl debug x
Common Syntax
% fw ctl debug –m fw conn drop ld packet if
The ld option may cause high CPU usage. It is advised to use it for short session debugging
only.
To execute the kernel you can also use fw ctl zdebug to allocate the buffer (where the
buffer can only be 1024).
% fw ctl zdebug
% fw ctl kdebug -f > <output file>
Check Point Troubleshooting and Debugging Tools for Faster Resolution. Last Update — July 16, 2006 2
User Mode Processes debugging
Usage
% fw debug <process name> <on/off> TDERROR_ALL_ALL=<value 1-5>
CPD is treated differently from the other User Mode processes and will be executed
differently, see “Debugging CPD” on page 3.
Debugging CPD
CPD is a high in the hierarchichal chain and helps to execute many services, such as Secure
Internal Communcation (SIC), Licensing and status report.
For CPD debug, execute: % cpd_admin debug on TDERROR_ALL_ALL=5
The debug file is located under $CPDIR/log/cpd.elg
To stop the CPD debug, execute: % cpd_admin debug off TDERROR_ALL_ALL=1
Debugging FWM
The FWM process is responsible for the execution of the database activities of the
SmartCenter server. It is; therefore, responsible for Policy installation, Management High
Availability (HA) Synchronization, saving the Policy, Database Read/Write action, Log
Display, etc.
For FWM debug, execute:
% fw debug fwm on TDERROR_ALL_ALL=5
% fw debug fwm on OPSEC_DEBUG_LEVEL=9
The debug file is located under $FWDIR/log/fwm.elg

To stop the FWM debug, execute:
% fw debug fwm off TDERROR_ALL_ALL=1
% fw debug fwm off OPSEC_DEBUG_LEVEL=1
Debugging FWD
The FWD process is responsible for logging. It is executed in relation to logging, Security
Servers and communication with OPSEC applications.
For FWD debug, execute: % fw debug fwd debug on TDERROR_ALL_ALL=5
The debug file is located under $FWDIR/log/fwd.elg
To stop the FWD debug, execute: % fw debug fwd off TDERROR_ALL_ALL=1
FireWall Monitor Network Capturing
The FireWall Monitor is responsible for packet flow analysis.
To execute: % fw monitor –e “accept;” –o <output file>
Security Server debugging
Debugging User Authentication
Usage
Debugging is done on the service itself (in.ahttpd, in.atelnetd, in.aftpd etc.)
% fw debug <process name> on TDERROR_ALL_ALL=5
The debug file is located under: $FWDIR/log/ahttpd.elg* or $FWDIR/log/aftpd.elg* or

$FWDIR/log/atelnetd.elg* depending on the service that you are debugging.
HTTP Security Server
For HTTP Security Server debug, execute:
% fw debug in.ahttpd on TDERROR_ALL_ALL=5
% fw debug in.ahttpd on OPSEC_DEBUG_LEVEL=3
The debug file is located under: $FWDIR/log/ahttpd.elg*

If more than one HTTP Security Server process is running, execute:
% fw kill fwd
% setenv TDERROR_ALL_ALL=5
% setenv OPSEC_DEBUG_LEVEL=3
% fwd –d >& <output file> &
Note - The setenv commands used above correlate with Unix environment. For other platforms,
execute the relevant command.
SMTP Security Server

To debug the SMTP Security Server, execute:
% fw debug in.asmtpd on TDERROR_ALL_ALL=5 .
The debug file is located under $FWDIR/log/asmtpd.elg*

To debug the mdq, execute the following commands:
% fw debug mdq on TDERROR_ALL_ALL=5 .
The debug file is located under $FWDIR/log/mdq.elg*

Debugging Session Authentication
To debug Session Authentication, execute:
% fw debug in.asessiond on TDERROR_ALL_ALL=5
The debug file is located under: $FWDIR/log/asessiond.elg*

Debugging Client Authentication
For HTTP to port 900, execute:
% fw debug in.ahclientd on TDERROR_ALL_ALL=5
For Telnet to port 259, execute:

% fw debug in.aclientd on TDERROR_ALL_ALL=5
The debug file is located under: $FWDIR/log/ahclientd.elg*

VPN debugging
On the Module
To start, execute:
% vpn debug trunc.
This command is equivalent to these two commands: vpn debug on, vpn debug ikeon.
To stop, execute:
% vpn debug off; vpn debug ikeoff .
The debug file is located under $FWDIR/log/ike.elg and $FWDIR/log/vpnd.elg

FireWall Monitor for packet flow analysis
% fw monitor –e “accept;” –o <output file>
Client Side
The Client side can only run under the root directory (C :/…)
To start, execute:
% sc debug on
To stop, execute:
% sc debug off
The debug file is located under sr_service_tde.log, under the SecuRemote installation
folder, for example: C:\Program files\CheckPoint\SecuRemote.
For packet capture from the Client side, execute:
% srfw monitor -e "accept;" -o <output file>
Provider-1 debugging
MDS Level
Most of the MDS actions are performed by the MDS’s fwm process, execute:
% mdsenv
% fw debug mds on TDERROR_ALL_ALL=5
% fw debug mds on OPSEC_DEBUG_LEVEL=9
The debug file is located under /opt/CPsuit-R60/fw1/log/mds.elg
CMA Level
See “FireWall Common debugging” on page 2.
VPN-1 VSX debugging
See “FireWall Common debugging” on page 2, either refer to user mode or kernel, as
necessary.
ClusterXL debugging
For ClusterXL debugging for Clustering, Synchronization, High Availability, Fail-over,
execute:
% cphaprob state
% cphaprob -ia list
% cphaprob -a if
% fw ctl pstat
Kernel debug for packet filter analysis

% fw ctl debug –m fw conn drop packet if sync
% fw ctl debug –m cluster all
Connectra debugging
For Connectra debugging issues relating to Web, files, Webmail, OWA, iNotes, Citrix, the
httpd process should be debugged:
To turn the debug on, under: $CVPNDIR/conf/httpd.conf change LogLevel to debug.

You should execute the process: cvpnrestart
The output is located at: $CVPNDIR/log/httpd.log
For debugging authentication issues, execute: Debug cvpnd
Run: cvpnd_admin debugset TDERROR_ALL_ALL=5
To start, execute: % cvpnrestart
The debug file is located under $CVPNDIR/log/cvpnd.elg
To stop debug, run:
% cvpnd_admin debug off
FireWall-1 GX debugging
See “FireWall Common debugging” on page 2.
% fw ctl debug –m fw conn drop ld packet filter
% fw ctl kdebug –T –f > <output file>
InterSpect debugging
% fw ctl debug –m fw conn drop packet if
Additional kernel debug options for InterSpect:

• portscan, for port scanning issues
• dynlog, for dynamic logging
• mail, for mail security in the kernel
• sam, for SAM IP address blocking
Kernel debug for Packet Drop, execute:

% fw ctl zdebug + drop
Kernel debug for SmartDefense TCP Streaming, execute:

% fw ctl zdebug + tcpstr + cifs
Kernel debug for Dynamic list (SAM), execute:

% fw tab -t sam_requests_v2 -u -f
% fw samp
SNX – SSL Network Extender debugging

Server Side
% vpn debug trunc
% vpn debug on slim=5
Debug can be found at $FWDIR/log/vpnd.elg.

You should execute vpn debug on [DEBUG_TOPIC=5]. The relevant debug topics are:
proxy, rasta, rasta_protocol and slim.)
Client Side
For the service:
Type regedit at the command prompt and set:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\cpextender\parameters\d
bg_level to 5
Open the Command Line interface window and execute:
% net stop cpextender
% net start cpextender (or kill slimsvc.exe)
The debug file is located under:

%Program Files%\CheckPoint\SSL Network Extender\slimsvc.log
For the ActiveX: (only when using ActiveX with Internet Explorer), type regedit at the
command prompt and set the following:
% set HKEY_CURRENT_USER\Software\CheckPoint\SSL Network
Extender\parameters\dbg_level to 5
The debug file is located under %APPDATA%\Check Point\extender\activex.log .

For the Applet: (when using the Applet version) SNX can be used by Microsoft JVM or by
other vendors (SUN, IBM…). To view the Java console when using Microsoft JVM you
need to check Java console enabled (requires restart) in the Internet Options Advanced tab
and restart Internet Explorer. You can also switch between the different JVMs (in case you
have two or more) in the same tab.
Further Debugging – Memory Diagnostics
The following utilities applies to all non-Windows systems supported by Check Point:
% free
% vmstat 2 10
% sar –k 2 10
% top
% ps -auxw
% cat /proc/meminfo
% cat /proc/slabinfo
Routing information
% arp –a
% netstat –ie
% netstat
How to use fw monitor 10-Jul-2003
Abstract
Inspecting network traffic is an essential part of today’s deployment and troubleshooting tasks. With fw
monitor Check Point provides a powerful built-in tool to simplify this task. fw monitor captures
network packets at multiple capture points within the FireWall-1 chain. These packets can be inspected
using industry-standard tools later on. This documents describes how to use fw monitor and use it’s
features to simplify the capturing tasks and provide the information you need.
Document Title: How to use fw monitor

Creation Date: 26-Feb-2003
Modified Date: 10-Jul-2003
Document Revision: 1.01
Product Class: FireWall-1 / VPN-1, fw monitor, SecuRemote/SecureClient, Ethereal, CPEthereal
Product and Version: FireWall-1/VPN-1 NG
Author: Bernd Ochsmann <bochsman@checkpoint.com, Udo Schneider <udos@checkpoint.com>
Table of Contents
ABSTRACT ...................................................................................................................................................................1
ACKNOWLEDGMENTS ................................................................................................................................................4
TYPOGRAPHIC CONVENTIONS USED IN THIS PAPER............................................................................................5
OVERVIEW....................................................................................................................................................................6
COMMAND SYNTAX ....................................................................................................................................................7
Break Sequence........................................................................................................................................................7
Printing the UUID or the SUUID [-u|s] .......................................................................................................................7
Flush standard output [-i]...........................................................................................................................................7
Debugging fw monitor [-d] / [-D] ................................................................................................................................7
Filter fw monitor packets <{-e expr}+|-f <filter-file|->>................................................................................................7
Limit the packet length [-l len]....................................................................................................................................9
Capture masks [-m mask] .........................................................................................................................................9
Print packet/payload data [-x offset[,len]] ..................................................................................................................9
Write output to file [-o <file>] ...................................................................................................................................10
Insert fw monitor chain module at a specifc position <[-pi pos] [-pI pos] [-po pos] [-pO pos] | -p all > .....................10
Use absolute chain positions [-a] ............................................................................................................................10
Capture a specific number of packets [-ci count] [-co count] ...................................................................................11
Capture on a specific Virtual Router or Virtual Machine [-vs vsid or vsname] .........................................................11
STANDARD USAGE ...................................................................................................................................................12
Using fw monitor .....................................................................................................................................................12

Reading fw monitor output ......................................................................................................................................12
How does fw monitor work? ....................................................................................................................................13
ADVANCED USAGE ...................................................................................................................................................14
Capture masks ........................................................................................................................................................14

Print packet/payload data........................................................................................................................................16
Limit the packet length ............................................................................................................................................17
Using UUIDs and SSIDs .........................................................................................................................................17
How to change the position of the fw monitor chain module ...................................................................................19
fw monitor filters ......................................................................................................................................................30
INSPECT FW MONITOR FILES ..................................................................................................................................39
Using snoop to inspect fw monitor files ...................................................................................................................39

Using tcpdump to inspect fw monitor files ...............................................................................................................42
Using Ethereal to inspect fw monitor files................................................................................................................43
Using CPEthereal to inspect fw monitor files...........................................................................................................55
SRFW – FW MONITOR ON THE CLIENT SIDE .........................................................................................................64
How to use fw monitor Page 2 of 70

Revision: 1.01
FW MONITOR ON FIREWALL-1 VSX ........................................................................................................................65
RESOURCES ..............................................................................................................................................................66
Secure Knowledge Links.........................................................................................................................................66

Detecting sniffers on your network ..........................................................................................................................67
snoop ......................................................................................................................................................................67
tcpdump ..................................................................................................................................................................67
Ethereal...................................................................................................................................................................67
CPEthereal..............................................................................................................................................................68
Miscellaneous .........................................................................................................................................................68
REFERENCE ...............................................................................................................................................................69
Multicast MAC addresses........................................................................................................................................69

fw monitor file format ...............................................................................................................................................69
UUID format ............................................................................................................................................................70

Revision: 1.01
Acknowledgments
Due to many questions and requests regarding fw monitor we developed the idea to write a “short”
paper about fw monitor. We thought 15-20 pages would be more than enough to cover all important
aspects of fw monitor …
As we started to collect information about fw monitor and related topics we soon discovered that there
was much more to write about than we initially thought. We had two choices: Writing a short note much
like a man page or choosing the long way and write a comprehensive manual. We decided for the second
and this paper is the result.
No way could we have completed this paper without the awesome help of many people who give us
invaluable feedback. We would like to thank Shaul Eizikovich for his fabulous CPEthereal; Misha Pak for
giving us deep insight in many fw monitor functionalities and mechanisms; Lior Cohen, Tal Manor and
Mark Wellins from Solutions Center for their great ongoing support; Joe Green for pointing us to missing
details we totally overlooked; our colleagues in the german Check Point Office who kept us working on
the paper by asking permanently for the final version; Alfred Köbler (ICON Systems GmbH) for initially
adding fw monitor decoding support to Ethereal, Manuela Menges (BASF IT Services GmbH) for
comments which where nearly as long as the whole document and to all others which provided comments
and suggestions.

Revision: 1.01
Typographic Conventions used in this paper
The following table describes the typographic conventions used in this paper.
Typeface or Meaning Example

Symbol
AaBbCc123 The names of commands, Use fw monitor –m iO to see all Pre-In and Post-Out
files, and directories; on- packets.
screen computer output.
AabBcC123 What you type, when

contrasted with on-screen
computer output. [cpmodule]# fw monitor -m iO
monitor: getting filter (from command
line)
monitor: compiling
AaBbCc123 Book titles or words to be Please refer to the FireWall-1 Getting Started Guide for
emphasized. further information.
AaBbCc123 Text that appears on an Use CheckPoint/Decode as FW-1 Monitor file to enable
object in a window. decoding.

Revision: 1.01
Overview
In many deployment and support scenarios capturing network packets is an essential functionality.
tcpdump or snoop are tools normally used for this task. fw monitor provides an even better
functionality but omits many requirements and risks of these tools.
‚ No Security Flaws
o tcpdump and snoop are normally used with network interface cards in promiscuous
mode. Unfortunately the promiscuous mode allows remote attacks against these tools
(see Snoop vulnerable to a remotely exploitable buffer overflow). fw monitor does not
use the promiscuous mode to capture packets.
In addition most FireWalls’ operating systems are hardened. In most cases this
hardening includes the removal of tools like tcpdump or snoop because of their security
risk.
‚ Available on all FireWall-1 installations
o fw monitor is a built-in firewall tool which needs no separate installation in case
capturing packets is needed. It is a functionality provided with the installation of the
FireWall package.
‚ Multiple capture positions within the FireWall-1 kernel module chain
o fw monitor allows you to capture packets at multiple capture positions within the
FireWall-1 kernel module chain; both for inbound and outbound packets. This enables
you to trace a packet through the different functionalities of the firewall.
‚ Same tool and syntax on all platforms
o Another important fact is the availability of fw monitor on different platforms. Tools like
snoop or tcpdump are often platform dependent or have specific “enhancements” on
certain platforms. fw monitor and all its’ related functionality and syntax is absolutely
identical across all platforms.
There is no need to learn any new “tricks” on an unknown platform.
Normally the Check Point kernel modules are used to perform several functions on packets (like filtering,
en- and decrypting, QoS …). fw monitor adds its own modules to capture packets. Therefore fw
monitor can capture all packets which are seen and/or forwarded by the FireWall.

Revision: 1.01
Command syntax
fw monitor [-u|s] [-i] [-d] [-D] <{-e expr}+|-f <filter-file|->> [-l len] [-m
mask] [-x offset[,len]] [-o <file>] <[-pi pos] [-pI pos] [-po pos] [-pO pos]
| -p all > [-a] [-ci count] [-co count] [-vs vsid or vsname]
Figure 1: fw monitor command line options
Break Sequence
Use ^C (that is Control + C) to stop fw monitor from capturing packets.
Printing the UUID or the SUUID [-u|s]
The option –u or –s is used to print UUIDs or SUUIDs for every packet. Please note that it is only
possible to print the UUID or the SUUID – not both. Please refer to Using UUIDs and SSIDs for further
information.
Flush standard output [-i]
Use –i to make sure that captured data for each packet is at once written to standard output. This is
especially useful if you want to kill a running fw monitor process and want to be sure that all data is
written to a file.
Debugging fw monitor [-d] / [-D]
The –d option is used to start fw monitor in debug mode. This will give you an insight into fw
monitor’s inner workings although this option is only rarely used outside Check Point. It’s also possible
to use –D to create an even more verbose output.
Filter fw monitor packets <{-e expr}+|-f <filter-file|->>
fw monitor has the ability to capture only packets in which you are interested in. It is possible to set the
filter expression on the command line (using the –e switch), read it from a file (-f) or to read it from
standard input (-f -). Please refer to fw monitor filters for a detailed description of the filter syntax.
In the following examples we are filtering for the 9th byte of the IP Header (‘accept [9:1]=1;’). The
9th byte is the IP protocol and we are only accepting IP protcol 1 which is ICMP.
Bas
When using filter expressions on the command line (using –e) you should make sure that they are
properly quoted. On Windows and UNIX Operating systems this can be done by surrounding the
! expression with single quote (' – ASCII Value 39) or double quotes (" – ASCII Value 34). Please
note that depending on your operating system and shell used there might be differences between
the two forms – especially when using special characters or (shell) variables in the filter expression.

Revision: 1.01
[Expert@cpmodule]# fw monitor -e 'accept [9:1]=1;'
monitor: getting filter (from command line)
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
eth0:i[84]: 172.16.1.1 -> 172.16.1.2 (ICMP) len=84 id=20919
ICMP: type=8 code=0 echo request id=6506 seq=256
eth0:I[84]: 172.16.1.1 -> 172.16.1.2 (ICMP) len=84 id=20919
eth0:o[84]: 172.16.1.2 -> 172.16.1.1 (ICMP) len=84 id=24617
ICMP: type=0 code=0 echo reply id=6506 seq=256
eth0:O[84]: 172.16.1.2 -> 172.16.1.1 (ICMP) len=84 id=24617
^C
monitor: caught sig 2
monitor: unloading
Figure 2: fw monitor – using filter expressions on the command line
[Expert@cpmodule]# echo "accept [9:1]=1;" >myfilter.pf

[Expert@cpmodule]# fw monitor -f myfilter.pf
monitor: getting filter (from myfilter.pf)
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
eth0:i[84]: 172.16.1.1 -> 172.16.1.2 (ICMP) len=84 id=21213
eth0:I[84]: 172.16.1.1 -> 172.16.1.2 (ICMP) len=84 id=21213
eth0:o[84]: 172.16.1.2 -> 172.16.1.1 (ICMP) len=84 id=24620
eth0:O[84]: 172.16.1.2 -> 172.16.1.1 (ICMP) len=84 id=24620
^C
monitor: unloading
Figure 3: fw monitor – using filter expressions in a file

Revision: 1.01
Please use ^D (that is Control + D) as EOF (End Of File) character when reading the filter expression
from standard input. fw monitor reads the expression just up to this point and processes it.
[Expert@cpmodule]# fw monitor -f -
monitor: getting filter (from stdin)
accept [9:1]=1;
^D
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
eth0:i[84]: 172.16.1.1 -> 172.16.1.2 (ICMP) len=84 id=21307
eth0:I[84]: 172.16.1.1 -> 172.16.1.2 (ICMP) len=84 id=21307
eth0:o[84]: 172.16.1.2 -> 172.16.1.1 (ICMP) len=84 id=24623
eth0:O[84]: 172.16.1.2 -> 172.16.1.1 (ICMP) len=84 id=24623
^C
monitor: unloading
Figure 4: fw monitor – reading filter expressions from standard input
Limit the packet length [-l len]
fw monitor allow you to limit the packet data which will be read from the kernel with -l. Refer to Limit
the packet length for further information. This is especially useful if you have to debug high sensitive
communication. It allows you to capture only the headers of a packet (e.g. IP and TCP header) while
omitting the actual payload. Therefore you can debug the communication without seeing the actual data
transmitted. Another possibility is to keep the amount of data low. If you don't need the actual payload for
debugging you can decrease the file site by omitting the payload. It’s also very useful to reduce packet
loss on high-loaded machines. fw monitor uses a buffer to transfer the packets from kernel to user
space. If you reduce the size of a single packet this buffer won’t fill up so fast.
Capture masks [-m mask]
By default fw monitor captures packets before and after the virtual machine in both directions (these
positions can be changed. Refer to How to change the position of the fw monitor chain module for more
information). The option –m options allows you to specify in which of the four positions you are interested.
For further information refer to Capture masks.
Print packet/payload data [-x offset[,len]]
In addition to the IP and Transport header fw monitor can also print the packets’ raw data. This can be
done using the –x option. Optionally it is also possible to limit the data written to the screen. Please refer
to Print packet/payload data for more information.

Revision: 1.01
Write output to file [-o <file>]
In addition to the ability to print out the packet’s information, fw monitor is also able to save the raw
packets’ data to a file. The file format used is the same format used by tools like snoop (Refer to Snoop
file format (RFC 1761) for further information). This file format can be examined using by tools like snoop,
tcpdump or Ethereal.
[Expert@cpmodule]# fw monitor -e 'accept ip_p=1;' -o ping.cap

monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
12
^C # of captured packets
monitor: unloading
Figure 5: fw monitor – writing raw packet data to a file
The snoop file format is normally used to store Layer 2 frames. For “normal” capture files this
means that the frame includes data like a source and a destination MAC address. fw monitor
! operates in the firewall kernel and therefore has no access to Layer 2 information like MAC
addresses anymore. Instead of writing random MAC addresses, fw monitor includes information
like interface name, direction and chain position as “MAC addresses”.
Insert fw monitor chain module at a specifc position <[-pi pos] [-pI pos] [-po pos] [-pO
pos] | -p all >
In addition to capture masks (which give you the ability to specify whether you are interested in packets in
a specific position) fw monitor has the ability to define where exactly (in the FireWall-1 chain) the
packets should be captured. This can be defined using –p[iIoO] [pos]. Please refer to How to
change the position of the fw monitor chain module for further information.
Use absolute chain positions [-a]
If you use fw monitor to output the capture into a file (option –o), one of the fields written down to the
capture file is the chain position of the fw monitor chain module. Together with an simultaneous
execution of fw ctl chain you can determine where the packet was captured (see How to change the
position of the fw monitor chain module for more information on this). Especially when using –p all you
will find the same packet captured multiples times at different chain positions.
The option –a changes the chain id from an relative value (which only makes sense with the matching fw
ctl chain output) to an absolute value. These absolute values are known to CPEthereal (see Using
CPEthereal to inspect fw monitor files) and can be displayed by it.

Revision: 1.01
Capture a specific number of packets [-ci count] [-co count]
fw monitor enables you to limit the number of packets being captured. This is especially useful in
situations where the firewall is filtering high amounts of traffic. In such situations fw monitor may bind
so many resources (for writing to the console or to a file) that recognizing the break sequence (Control-C)
might take very long.
[Expert@cpmodule]# fw monitor -ci 3 -o dump1.cap

monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
12
monitor: unloading
Read 3 inbound packets and 3 outbound packets
[Expert@cpmodule]# fw monitor -co 3 -o dump2.cap
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
14
monitor: unloading
Read 4 inbound packets and 3 outbound packets
Figure 6: fw monitor – capture a specific number of packets
fw monitor counts "real" packets. In the example above we decided to capture just 3 packets. But the
packet counter was 12 and 14. This can be explained by the multiple capture positions. In the first
example we had three inbound and three outbound packets (six in sum). Each packet is counted to times
(preInbound/postInbound or preOutbund/postOutbound):
3 (inbound) * 2 (pre/post) + 3 (outbound) * 2 (pre/post) = 12 packets.
The same for the second example:
4 (inbound) * 2 (pre/post) + 3 (outbound) * 2 (pre/post) = 14 packets.
! Please note that it is possible to use the –ci and the –co switches together. fw monitor will stop
capturing packets if the number of packets for one of the two counters reaches it’s value.
Capture on a specific Virtual Router or Virtual Machine [-vs vsid or vsname]
FireWall-1 VSX enables you to run multiple Virtual Routers and FireWalls on one physical machine. Using
the option –vs you can specify on which virtual component the packets should be captured. This option is
only available on a FireWall-1 VSX module – not on a standard module. Please refer to fw monitor on
FireWall-1 VSX for more information.

Revision: 1.01
Standard Usage
Using fw monitor
The easiest way to use fw monitor is to invoke it without any parameter. This will output every packet
from every interface that passes (or at least reaches) the enforcement module. Please note that the same
packet is appearing several times (two times in the example below). This is caused by fw monitor
capturing the packets at different capture points. Please refer to Capture masks for a more detailed
explanation.
[cpmodule]# fw monitor
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
eth0:i[285]: 172.16.1.133 -> 172.16.1.2 (TCP) len=285 id=1075
TCP: 1050 -> 18190 ...PA. seq=bf8bc98e ack=941b05bc
eth0:I[285]: 172.16.1.133 -> 172.16.1.2 (TCP) len=285 id=1075
eth0:o[197]: 172.16.1.2 -> 172.16.1.133 (TCP) len=197 id=44599
TCP: 18190 -> 1050 ...PA. seq=941b05bc ack=bf8bca83
eth0:O[197]: 172.16.1.2 -> 172.16.1.133 (TCP) len=197 id=44599
TCP: 18190 -> 1050 ...PA. seq=941b05bc ack=bf8bca83
eth0:o[1500]: 172.16.1.2 -> 172.16.1.133 (TCP) len=1500 id=44600
TCP: 18190 -> 1050 ....A. seq=941b0659 ack=bf8bca83
^C
monitor: unloading
Figure 7: Invoking fw monitor without parameters
Reading fw monitor output
eth0:i[285]: 172.16.1.133 -> 172.16.1.2 (TCP) len=285 id=1075

Figure 8: Reading fw monitor output – first line
This packet was captured on the first network interface (eth0) in inbound direction before the virtual
machine (lowercase i; see Capture masks for a more detailed explanation). The packet length is 285
bytes (in square parenthesis; repeated at the end of the line. Please not that these two values may be
different. Refer to the Virtual Defragmentation note for further information) and the packets ID is 1075.
The packet was sent from 172.16.1.133 to 172.16.1.2 and carries a TCP header/payload.

Revision: 1.01
Figure 9: Reading fw monitor output – second line
The second line tells us that this is an TCP payload inside the IP packet which was sent from port 1050 to
port 18190. The following element displays the TCP flags set (in this case PUSH and ACK). The last two
elements are showing the sequence number (seq=bf8bc98e) of the TCP packet and the acknowledged
sequence number (ack=941b05bc). You will see similar information for UDP packets.
You will only see a second line if the transport protocol used is known to fw monitor. Known
! protocols are for example TCP, UDP and ICMP. If the transport protocol is unknown or can not be
analyzed because it is encrypted (e.g. ESP or encapsulated (e.g. GRE) the second line is missing.
How does fw monitor work?
In contrast to other capturing tools like snoop or tcpdump, fw monitor does not use the promiscuous
mode on network interface cards. Based on the fact that FireWall-1 already receives all packets (due to
the FireWall-1 kernel module between NIC driver and IP stack) fw monitor uses it’s own kernel module
to capture packets (compared to filtering/encrypting them).
Unlike snoop or tcpdump, fw monitor has the ability to capture packets at different positions (refer to
Capture position for more information about the four locations) in the FireWall-1 kernel module chain.
snoop and tcpdump are capturing packets when they enter or leave the computer. Especially when NAT
with FireWall-1 is involved fw monitor offers the possibility to capture packets at multiple locations (e.g.
after the FireWall Virtual in inbound direction). This can help you to see how the packets are translated by
the firewall and on which IP address the routing decission is made.

Revision: 1.01
Advanced usage
Capture masks
fw monitor is able to capture packets at four different positions in the FireWall-1 chain:
‚ on the inbound interface before the Virtual Machine (pre-inbound)
‚ on the inbound interface after the Virtual Machine (post-inbound)
‚ on the outbound interface before the Virtual Machine (pre-outbound)
‚ on the outbound interface after the Virtual Machine (post-outbound)
App. App.
TCP TCP
IP Routing IP
post-inbound (I) pre-inbound (o)
VM VM
pre-inbound (i) post-outbound (O)
NIC NIC
Figure 10: fw monitor capture positions
! The picture above is a simplified figure of the actual implementation. To find out more please refer to
How to change the position of the fw monitor chain module for more information.

Revision: 1.01
By default fw monitor captures packets at all four positions. With -m it is possible to capture packets at
specific positons. fw monitor uses single letters as indicators for the position:
Capture position fw monitor mask value

pre-inbound i (lowercase i)
post-inbound I (uppercase i)
pre-outbound o (lowercase o)
post-outbound O (uppercase o)
Figure 11: fw monitor capture position masks
Using fw monitor masks it’s easily possible to capture only packets before they are inspected by the
firewall in inbound direction and after they have been inspected by the firewall in outbound direction.
fw monitor capture mask example
In the example below we are capturing a communication between a client (10.2.4.12) and a web server
(172.16.1.1). The client address is translated to 172.16.1.3 and the server address is translated to
10.2.253.2. You can easily see how the non-translated packet enters the firewall and how the translated
packet (source and destination) is leaving the firewall:
[Expert@cpmodule]# fw monitor -m iO
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
eth1:i[60]: 10.2.4.12 -> 10.2.254.2 (TCP) len=60 id=41817
TCP: 34762 -> 80 .S.... seq=e8527fe7 ack=00000000
eth0:O[60]: 172.16.1.3 -> 172.16.1.1 (TCP) len=60 id=41817
TCP: 34762 -> 80 .S.... seq=e8527fe7 ack=00000000
eth0:i[60]: 172.16.1.1 -> 172.16.1.3 (TCP) len=60 id=41818
TCP: 80 -> 34762 .S..A. seq=e7c90e3e ack=e8527fe8
eth1:O[60]: 10.2.254.2 -> 10.2.4.12 (TCP) len=60 id=41818
TCP: 80 -> 34762 .S..A. seq=e7c90e3e ack=e8527fe8
eth1:i[52]: 10.2.4.12 -> 10.2.254.2 (TCP) len=52 id=41819
TCP: 34762 -> 80 ....A. seq=e8527fe8 ack=e7c90e3f
eth0:O[52]: 172.16.1.3 -> 172.16.1.1 (TCP) len=52 id=41819
TCP: 34762 -> 80 ....A. seq=e8527fe8 ack=e7c90e3f
^C
monitor: unloading
Figure 12: Using fw monitor capture masks
Using the right combination of capture masks it’s very easy to find out when the firewall applies which
NAT rules (Hide NAT, Static Destination NAT or Static Source NAT). This is especially useful when you
need to know which packets the routing of the operating system is using to do the routing decision.

Revision: 1.01
Print packet/payload data
Using –x it’s possible to print the packet’s raw data. You have to specify a specific offset (e.g. used to
jump over the IP/TCP header) from which the packet data is printed. It’s also possible to limit the length of
the raw data:
In the following example we are skipping the IP and TCP header (offset 52) and are using a length of 96:
[Expert@cpmodule]# fw monitor -m i -x 52,96

monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
eth1:i[60]: 10.2.4.12 -> 10.2.254.2 (TCP) len=60 id=18687
TCP: 36242 -> 80 .S.... seq=afe21c6a ack=00000000
0000 0000 0103 0300 ........
eth0:i[60]: 172.16.1.1 -> 172.16.1.3 (TCP) len=60 id=18688

TCP: 80 -> 36242 .S..A. seq=b060b1df ack=afe21c6b
0198 23ef 0103 0300 ..#.....
eth1:i[52]: 10.2.4.12 -> 10.2.254.2 (TCP) len=52 id=18689

TCP: 36242 -> 80 ....A. seq=afe21c6b ack=b060b1e0
eth1:i[594]: 10.2.4.12 -> 10.2.254.2 (TCP) len=594 id=18690

TCP: 36242 -> 80 ...PA. seq=afe21c6b ack=b060b1e0
4745 5420 2f43 504c 6f67 6f48 6f72 697a GET /CPLogoHoriz
5075 7270 2e67 6966 2048 5454 502f 312e Purp.gif HTTP/1.
310d 0a48 6f73 743a 2031 302e 1..Host: 10.
eth0:i[52]: 172.16.1.1 -> 172.16.1.3 (TCP) len=52 id=18691

TCP: 80 -> 36242 ....A. seq=b060b1e0 ack=afe21e89
eth0:i[288]: 172.16.1.1 -> 172.16.1.3 (TCP) len=288 id=18692

TCP: 80 -> 36242 ...PA. seq=b060b1e0 ack=afe21e89
4854 5450 2f31 2e31 2033 3034 204e 6f74 HTTP/1.1 304 Not
204d 6f64 6966 6965 640d 0a53 6572 7665 Modified..Serve
723a 2074 6874 7470 642f 322e r: thttpd/2.
^C
monitor: unloading
Figure 13: fw monitor – printing packet raw data

Revision: 1.01
Limit the packet length
fw monitor can limit the amount of packet data which will be read from the kernel. The option –l is
used for this purpose. fw monitor will only read as many bytes from the kernel as you specified for the
–l option. Please make sure to capture as least as many bytes so that the IP and transport headers are
included.
Using UUIDs and SSIDs
UUIDs (universal-unique-identifiers) are a new feature in NG. The firewall assigns an UUID to every
connection passing the firewall. This UUID is kept through all firewall operations. Therefore you can follow
a connection through the firewall even if the packet content is NAT’ed. The UUID is also kept in the
connection table entry for the connection.
Additionally there is the concept of an SUUID (Session UUID). For services which are using several
connections (e.g. FTP) every connection has a unique UUID but the SUUID is equal for all the
connections (it’s the same as the first/control connection’s UUID).
UUIDs and SUIDs are very helpful for tracking connection through different chain modules of the firewall.
Even if a connection is NAT’ed the UUID or SUID remains the same. Therefore filtering for the UUID or
SUID helps you to find all packets belonging to a connection or session, even if the packets change.
Please note that the first packet of a connection or session as no UUID or SUID assigned yet (SUID/SUID
is all zero). After the first packet has been processed by the firewall a UUID or SUID is assigned and will
remain the same for the whole connection/session.
An UUID is built from four 32bit values using a timestamp, a counter, the firewall IP address and a
process ID. From this 128bit value a smaller 32bit value is constructed which is printed as well. Please
refer to UUID format for detailed information.
The UUID/SUUID is printed in front of the IP information. The first value is the striped UUID (32bit). The
second value is the complete UUID (128bit).

Revision: 1.01
[Expert@cpmodule]# fw monitor -u
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
[00000000 - 00000000 00000000 00000000 00000000]:eth1:i[60]: 10.2.4.12 -> 10.2.254.2 (TCP) len=60 id=46124
TCP: 34838 -> 80 .S.... seq=5c2282fa ack=00000000
[6b770000 - 3e5c776b 00000000 020110ac 000007b6]:eth1:I[60]: 10.2.4.12 -> 172.16.1.1 (TCP) len=60 id=46124
TCP: 34838 -> 80 .S.... seq=5c2282fa ack=00000000
[6b770000 - 3e5c776b 00000000 020110ac 000007b6]:eth0:o[60]: 10.2.4.12 -> 172.16.1.1 (TCP) len=60 id=46124
TCP: 34838 -> 80 .S.... seq=5c2282fa ack=00000000
[6b770000 - 3e5c776b 00000000 020110ac 000007b6]:eth0:O[60]: 172.16.1.3 -> 172.16.1.1 (TCP) len=60 id=46124
TCP: 34838 -> 80 .S.... seq=5c2282fa ack=00000000
[6b770000 - 3e5c776b 00000000 020110ac 000007b6]:eth0:i[60]: 172.16.1.1 -> 172.16.1.3 (TCP) len=60 id=46125
TCP: 80 -> 34838 .S..A. seq=5c3b9465 ack=5c2282fb
[6b770000 - 3e5c776b 00000000 020110ac 000007b6]:eth1:i[52]: 10.2.4.12 -> 10.2.254.2 (TCP) len=52 id=46126
TCP: 34838 -> 80 ....A. seq=5c2282fb ack=5c3b9466
^C
monitor: unloading
Figure 14: fw monitor UUID output
! Please note that new connections are using a UUID of 0x0000…. Once they have been “seen” by
the firewall module a UUID is assigned and maintained.

Revision: 1.01
How to change the position of the fw monitor chain module
In Capture masks we described fw monitor capture masks. The positions were defined to be before
the virtual machine and after the virtual machine. Although not wrong it is not completely right.
Check Point uses a so called “kernel module chain” for different kernel modules which are working with
the packets. The different modules (Firewall, VPN , FloodGate … ) are passing on a packet to the next
module and building up a kind of chain this way.
The example below shows how the packets is processed by different chain modules while entering and
leaving the firewall machine:
TCP/IP TCP/IP
RTM/E2E Virtual Reass

IP Side Acct
IQ Engine
VM
FG Policy NAT
VPN Policy VPN Policy
Outbound
Inbound
Accounting FG Policy
NAT VPN Enc

VM
IQ Engine
VPN Verify
VPN Dec Accounting
Virtual Reass
Wire Side Acct RTM/E2E
NIC NIC
Figure 15: FireWall chain – schematic overview
You can take a look at the actual chain using the fw ctl chain command. This will show you the chain
modules actually loaded on your machine and their order. Please note that there are more kernel
modules in the chain which are not visible by fw ctl chain and also cannot be used for fw monitor
kernel module positioning.

Revision: 1.01
[Expert@cpmodule]# fw ctl chain
in chain (9):
0: -7f800000 (ca8d9698) IP Options Strip (ipopt_strip)
1: - 2000000 (cb1c1c64) vpn decrypt (vpn)
2: - 1fffff6 (ca8da0f8) Stateless verifications (asm)
3: - 1fffff0 (cb1c17f0) vpn decrypt verify (vpn_ver)
4: - 1000000 (ca8eb688) SecureXL connection syn (secxl_sync)
5: 0 (ca8aa0c0) fw VM inbound (fw)
6: 2000000 (cb1c2aa0) vpn policy inbound (vpn_pol)
7: 10000000 (ca8eb728) SecureXL inbound (secxl)
8: 7f800000 (ca8d98e4) IP Options Restore (ipopt_res)
out chain (8):
1: - 1ffffff (cb1c16fc) vpn nat outbound (vpn_nat)
2: - 1f00000 (ca8da0f8) Stateless verifications (asm)
3: 0 (ca8aa0c0) fw VM outbound (fw)
4: 2000000 (cb1c26e0) vpn policy outbound (vpn_pol)
5: 10000000 (ca8eb728) SecureXL outbound (secxl)
6: 20000000 (cb1c2164) vpn encrypt (vpn)
Figure 16: fw ctl chain output
The output of fw ctl chain is platform, version and product dependent. There is no reason to
! worry if your fw ctl chain output looks different. The number and kind of modules displayed here
may vary based on the platform used and products installed. Please note that even the offsets
shown here are version dependent and may change.
fw monitor inserts its own modules in this module chain and is capturing packets there. By default this
is not the first and last position in the chain. Therefore the original meaning of before and after needs to
be redefined:
‚ Without changing the position of the kernel module everything is quite simple:
o Before can be interpreted as being before any firewall, VPN or NAT action.
o After is defined as being after and NAT or VPN operation has occurred.
‚ If you change the kernel module position using –p (see How to change the position of the fw
monitor chain module) but do not capture at all positions (see All positions):
o Before (pre-inbound /pre-outbound) describes the first instance of the fw monitor
kernel module (although it may be after the VM!)
o After (post-inbound/post-outbound) describes the second instance of the fw monitor
kernel module (although in fact, like above, it may be before the VM).
‚ If you are using –p all to capture packets between every kernel module (see All positions):
o All packets captured between the kernel module before the VM are marked as being pre-
inbound/pre-outbound
o All packets captured after the VM are marked as being post-inbound/post-outbound.
Due to the fact that the fw monitor chain module is a “normal” chain module there are some
! issues one should be aware of. All chain modules are working on already (virtual) defragmented
packets. Even if a packet is fragmented fw monitor will show the defragmented packet, not the
fragments.

Revision: 1.01
The virtual defragmentation may lead to some confusion when working with fragmented packets: fw
monitor captures defragmented packets but some of the info about the packet is taken from the
first IP fragment. This may lead to two “anomalies”:
1. If you are printing fw monitor output to standard output you may see two different size
values:
! hme1:i[828] 10.0.0.1 -> 10.0.0.2 (ICMP) len=420 id=224 off=0
In this example here the first length (square parenthesis) is 828 Bytes. This is the length of
the defragmented packet. The second size (len=) is 420 Bytes. This is the size of the first
IP Fragment. This may also cause “invalid packets” in Ethereal because the size in the IP
header (430 bytes here) is different from the size of the actual packet.
2. In addition it may be that the “more fragments” bit is set in the IP header, although the
packet itself is already defragmented.
If fw monitor is active you can see the fw monitor chain modules using fw ctl chain:
[Expert@cpmodule]# fw monitor -o dump.cap

monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
Switch to another terminal
[cpmodule]# fw ctl chain

in chain (11):
1: -70000000 (ca8c6020) fwmonitor (i/f side)
9: 70000000 (ca8c6020) fwmonitor (IP side)
out chain (10):
1: -70000000 (ca8c6020) fwmonitor (IP side)
8: 70000000 (ca8c6020) fwmonitor (i/f side)
Figure 17: fw monitor modules in firewall chain

Revision: 1.01
[cpmodule]# fw ctl chain
in chain (11):
1: -70000000 (ca8c6020) fwmonitor (i/f side)
out chain (10):
Figure 18: fw monitor modules in firewall chain
In inbound direction all chain positions before the firewall are considered to be preInbound. All chain
modules after the firewall VM are postInbound.
In outbound direction all chain position before the firewall VM are considered to be preOutbound. All
chain modules after the VM are postOutbound.
The –p[iIoO] switch allows you to insert the fw monitor module at different positions in the chain.
The letters “iIoO” are used with the same meaning like the fw monitor capture masks. There are four
possibilities to define the position of the fw monitor module in the chain:
‚ relative position using a number

‚ relative position using an alias
‚ absolute position
‚ all positions

Revision: 1.01
Relative position using a Number
The chain modules are ordered with an ascending number starting with zero: You can use this number to
specify the position where the fw monitor module should be inserted. The fw monitor module does
no replace the module with this number. The previous module (and all following modules) are moved by
one position:

in chain (9):
out chain (8):
Figure 19: fw ctl chain – relative module positions

Revision: 1.01
In the following example we are inserting the fw monitor chain module preInbound (i) at position 4:
[Expert@cpmodule]# fw monitor -pi 4 -o dump.cap

monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
in chain (11):
4: - 1000001 (ca8c6020) fwmonitor (i/f side)
out chain (10):
13
^C
monitor: unloading
Figure 20: fw monitor – relative positioning using a module number
Please note that the relative positions, the number and the order of the modules is in no way fixed.
Every change of the configuration or installed products may change this. If you are using relative
! number you should use fw ctl chain to verify the positions you intended to use. Another
possibility is to use aliases for the modules. Even if the position of the module may change the alias
remains the same.

Revision: 1.01
Relative position using an Alias
Another possibility to specify the position of the fw monitor module is to use a modules alias (shown in
parenthesis). Compared to the relative positioning by numbers you have the additional possibility to
decide whether you want to insert the fw monitor module before or after the module you specified. This
can be done using + or – in front of the module alias:

in chain (9):
out chain (8):
Figure 21: fw ctl chain – module aliases

Revision: 1.01
In the following example we are inserting the fw monitor chain module before (-) SecureXL connection
synchronization (secxl_sync):
[Expert@cpmodule]# fw monitor -pi -secxl_sync -o dump.cap

monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
in chain (11):
4: - 1000001 (ca8c6020) fwmonitor (i/f side)
out chain (10):
48
^C
monitor: unloading
Figure 22: fw monitor – relative positioning using module aliases

Revision: 1.01
Absolute position
Although in most cases the use of aliases for positioning is recommended it is also possible to use
absolute positioning. This allows you to specify the position to insert the fw monitor module using its
absolute position. Every chain module as such a position and the kernel sorts them according to this
position. The absolute position is printed in hex after the relative position. Please note that chain positions
before the virtual machine are negative values:

in chain (9):
out chain (8):
Figure 23: fw ctl chain – absolute positions
! Please note that the absolute position is a property of the kernel module assigned by Check Point
R&D: This value may change in future versions.

Revision: 1.01
[Expert@cpmodule]# fw monitor -pi -0x1ffffe0 -pO 0x20000001
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
in chain (11):
4: - 1ffffe0 (ca8c6020) fwmonitor (i/f side)
out chain (10):
^C
monitor: unloading
Figure 24: fw monitor – absolute positioning
! fw ctl chain does not show the preceding 0x to specify hex numbers. Nevertheless you have to
add a preceding 0x in front of the number to use it with fw monitor.

Revision: 1.01
All positions
A new option in NG with Application Intelligence (FP4) allows you to insert fw monitor modules
between all modules. This gives you the ability to follow a packet through the FireWall-1 kernel module
chain. The position where the packet was captured is printed after the direction (module in parenthesis)
and also written down to the capture file if the –o option is used..
[Expert@cpmodule]# fw monitor -p all

monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
in chain (9):
out chain (8):
eth0:i0 (IP Options Strip)[84]: 172.16.1.1 -> 172.16.1.2 (ICMP) len=84 id=11936
eth0:i1 (vpn decrypt)[84]: 172.16.1.1 -> 172.16.1.2 (ICMP) len=84 id=11936
eth0:i2 (Stateless verifications)[84]: 172.16.1.1 -> 172.16.1.2 (ICMP) len=84 id=11936
eth0:i3 (vpn decrypt verify)[84]: 172.16.1.1 -> 172.16.1.2 (ICMP) len=84 id=11936
eth0:i4 (SecureXL connection syn)[84]: 172.16.1.1 -> 172.16.1.2 (ICMP) len=84 id=11936
eth0:i5 (fw VM inbound )[84]: 172.16.1.1 -> 172.16.1.2 (ICMP) len=84 id=11936
eth0:I6 (vpn policy inbound)[84]: 172.16.1.1 -> 172.16.1.2 (ICMP) len=84 id=11936
eth0:I7 (SecureXL inbound)[84]: 172.16.1.1 -> 172.16.1.2 (ICMP) len=84 id=11936
eth0:I8 (IP Options Restore)[84]: 172.16.1.1 -> 172.16.1.2 (ICMP) len=84 id=11936
eth0:I9 (Chain End)[84]: 172.16.1.1 -> 172.16.1.2 (ICMP) len=84 id=11936
eth0:o0 (IP Options Strip)[84]: 172.16.1.2 -> 172.16.1.1 (ICMP) len=84 id=49943
eth0:o1 (vpn nat outbound)[84]: 172.16.1.2 -> 172.16.1.1 (ICMP) len=84 id=49943
eth0:o2 (Stateless verifications)[84]: 172.16.1.2 -> 172.16.1.1 (ICMP) len=84 id=49943
eth0:o3 (fw VM outbound)[84]: 172.16.1.2 -> 172.16.1.1 (ICMP) len=84 id=49943
eth0:O4 (vpn policy outbound)[84]: 172.16.1.2 -> 172.16.1.1 (ICMP) len=84 id=49943
eth0:O5 (SecureXL outbound)[84]: 172.16.1.2 -> 172.16.1.1 (ICMP) len=84 id=49943
eth0:O6 (vpn encrypt)[84]: 172.16.1.2 -> 172.16.1.1 (ICMP) len=84 id=49943
eth0:O7 (IP Options Restore)[84]: 172.16.1.2 -> 172.16.1.1 (ICMP) len=84 id=49943
eth0:O8 (Chain End)[84]: 172.16.1.2 -> 172.16.1.1 (ICMP) len=84 id=49943
^C
monitor: unloading
Figure 25: fw monitor – all positions

Revision: 1.01
It is not recommended to use this option on a high-loaded production machine, except that you add
! specific filters to reduce the output. Without a filter it may output more than 15 captured packets (in
this example 8 packets inbound and 9 packets outbound) per packet passing the firewall.
fw monitor filters
fw monitor filters are using a subset of INSPECT to specify the packets to be captured. The general
syntax is:
accept expression;
Figure 26: fw monitor filter expression – general syntax
“accept” in fw monitor filters does not mean that packets are actually accepted by the firewall.
! fw monitor captures all packets which are accepted by the filter and discards the rest. A filter like
accept; (capturing all packets) will in no way change the behavior of the FireWall and its rulebase.
The complexity of an expression can vary from a simple test (checking for a specific value at a specific
offset) to a complex expression using different checks and logical operators.
Simple Checks
Simple checks are used to check for a value at a specific offset in the packet:
[ offset : length , order ] relational-operator value

Figure 27: fw monitor simple checks – general syntax
offset specifies the offset relative to the beginning of the IP packet from where the value should be
read.
length specifies the number of bytes and can be 1 (byte), 2 (word) or 4 (dword). If length is not
specified fw monitor assumes 4 (dword).
order is used to specify the byte order. Possible values are b (big endian) or l (little endian, or host
order). If order is not specified little endian byte order is assumed.
relational-operator is a relational operator to express the relation between the packet data and the
value.
value is one of the data types known to INSPECT (e.g. an IP address or an integer).

Revision: 1.01
1st Byte 2nd Byte 3rd Byte 4th Byte
Bits 24-31 Bits 16-23 Bits 8-15 Bits 0-7
Figure 28: Big Endian byte order
Big Endian order means that the most significant byte as the lowest address (the word is stored ‘big-
endian-first’)
1st Byte 2nd Byte 3rd Byte 4th Byte
Bits 0-7 Bits 8-15 Bits 16-23 Bits 24-31
Figure 29: Little Endian byte order
Little Endian order means that bytes at lower addresses have lower significance (the word is stored ‘little-
endian-first’)
Please note that the byte order is proccessor architecture dependent. On proccessors like Motorla 68xxx
big endian byte order is used. Little endian byte order is used e.g. by Intel 386 and compatible
processors. There are also processors which are able to work with both byte orders (e.g. PowerPC). You
can find more information about byte orders at An Essay on Endian Order.

Revision: 1.01
To filter for specific values it is essential to know where these values are stored. Therefore it is important
to know the different protocols and their fields:
0 8 16 24 32
header
version type of service (TOS) total length
length
identification (ID) flags fragment offset
time-to-live (TTL) protocol header checksum
source IP address
destination IP address
IP options (if any)
IP payload
Figure 30: IP protocols – IP header
0 8 16 24 32
ICMP type ICMP code ICMP checksum
content based on type and code
Figure 31: IP protocols – ICMP header
0 8 16 24 32
UDP source port number UDP destination port number
UDP length UDP checksum
UDP payload (if any)
Figure 32: IP protocols – UDP header

Revision: 1.01
0 8 16 24 32
TCP source port number TCP destination port number
TCP sequence number
TCP acknoledgment number

URG
ACK
PSH
SYN
RST
FYN
header
reserved TCP window size
length
TCP checksum TCP urgent pointer
TCP options (if any)
TCP payload (if any)
Figure 33: IP protocols – TCP header
Simple Checks can be used for a wide variety of checks. Some examples:
Filter on source or destination IP address. The IP addresses are stored as dwords at offset 12 (source
address) and 16 (destination address):
address filter expression

source accept [12, b]=172.16.1.2;
destination accept [16, b]=10.2.4.12;
Figure 34: fw monitor simple checks – IP addresses
Please note the use of IP addresses instead of simple numbers in the example above. INSPECT
! “knows” IP addresses and converts them automatically to an integer. There is no need to do this
manually although this is possible. Please refer to the Check Point Reference Guide for more
information.
Filter on the IP protocol. The IP protocol is stored as a byte at offset 9 in the IP packet:
IP protocol filter expression

ICMP accept [9:1] = 1;
TCP accept [9:1] = 6;
UDP accept [9:1] = 17;
ESP accept [9:1] = 50;
Figure 35: fw monitor simple checks – IP protocol examples

Revision: 1.01
Filter on ports (when using TCP or UDP). The ports are stored as a word at offset 20 (source port) and 22
(destination port):
IP protocol filter expression

source port HTTP accept [20:2,b]=80;
destination port HTTP accept [22:2,b]=80;
source port FTP (control channel) accept [20:2,b]=21;
destination port FTP (control channel) accept [22:2,b]=21;
Figure 36: fw monitor simple checks – TCP/UDP ports examples
Network checks
INSPECT allows you to check whether a specific IP address belongs to a specified network. There are
two possibilities to achieve this:
accept netof [IP Address] = [Network Address];

Figure 37: simple network checks – expression syntax
accept netof src = 172.16.1.0;

Figure 38: simple network checks – example
Although this is very easy to use and to remember it has one limitation: It is not possible to define the
subnet mask to be used. Instead the subnet mask is automatically determined by the IP address.
The second possibility allows you to specify an IP range – therefore enabling you to filter not only for
none-implied subnet masks but even for IP address ranges:
[listname] = { [ IP address ranges ] };

accept [IP address] in [listname];
Figure 39: advanced network checks – expression syntax
internal = { <172.16.1.0, 172.16.1.255>, <172.16.8.0,172.16.8.255> };

accept (src in internal);
Figure 40: advanced network checks – example
Please note the it is possible to include multiple networks in a list. This allows you e.g. to define all your
internal networks and use the resulting list in the filter expression.
Data types
INSPECT knows several native data types. Just some of them are useful for fw monitor:
Hexadecimal Integers A number beginning with 0x e.g. 0x5ab4

Octal Integers A Number beginning with 0 e.g. 0777
Decimal Integers Any other number e.g. 23
IP Address Four decimal integers separated by three periods e.g. 172.45.2.4
Figure 41: fw monitor – data types

Revision: 1.01
Logical and Relational Operators
In addition to the single expressions testing for equality it is possible to combine different expressions
using several logical and relational operators
< Less than

> Greater than
<= Less than or equal to
>= Greater than or equal to
= or is Equal
!= or is not Not equal
Figure 42: fw monitor – Relational Operators
, Logical AND
or Logical Or
xor Logical XOR
not Logcial NOT
Figure 43: fw monitor – Logical Operators
Please note that INSPECT uses another operator precedence than e.g. C. In INSPECT the
! expression “a , b or c” is understood as “a , ( b or c)”. That is, or takes precedence over

, (and). Parentheses “(“ and “)” – can be used to force operator precedence. There is no penalty
for redundant parentheses..
Using relational and logical operators it is easily possible to build complex capture filters:
Everything except http accept not ( [20:2,b]=80 or [22:2,b]=80);

Every non-root TCP connection accept [9:1]=9 , th_sport > 1024;
Every TCP packet between accept [9:1]=9 , (([12:4,b]=10.2.4.12 ,
10.2.4.12 and 172.16.1.2 [16:4,b]=172.16.1.2) or ([12:4,b]=172.16.1.2 ,
[16:4,b]=10.2.4.12));
Figure 44: fw monitor – example of logical and relational operators
Even if fw monitor filters allow you to specify complex filters it’s normally not advisable. In many
cases a too complex filter might not capture packets you are interested in. It’s normally better to just
! filter out bulk traffic you’re not interested in (e.g. HTTP) and do the granular filtering later on (e.g.
using Ethereal on files generated with -o). An exception is using fw monitor on high-loaded
gateways. There you might have simply no choice but to reduce the amiunt of traffic being captured.

Revision: 1.01
Macros
Because all offsets, lengths and orders are hard to remember fw monitor offers an more intuitive way of
specifying the desired field:
Field Macro Expression

source address src [12:4,b]
destination address dst [16:4,b]
source port sport [20:2,b]
destination port dport [22:2,b]
Figure 45: fw monitor – built-in macros
Using these macros it very easy to define filters (and understanding them again a few weeks later!):
Everything except http accept not ( sport=80 or dport=80);

All TCP packets sdn between accept [9:1]=9 , ((src=10.2.4.12 , dst=172.16.1.2) or
host 10.2.4.12 and 172.16.1.2 (src=172.16.1.2 , dst=10.2.4.12));
Figure 46: fw monitor – example of logical and relational operators using macros
These macros are not a part of INSPECT. INSPECT (and therefore fw monitor as well) uses a C
preprocessor to replace named macros with their low-level equivalents. If you are using filters on the
command line (using –e) fw monitor creates a new file with the definitions above and appends your
filter expression. The file is called $FWDIR/tmp/monitorfilter.pf:
[Expert@cpmodule]# fw monitor -e 'accept src=10.2.4.12 or dst=10.2.4.12;'

monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
^C
monitor: unloading
[Expert@cpmodule]# cat $FWDIR/tmp/monitorfilter.pf
#define src ip_src
#define dst ip_dst
#define sport th_sport
#define dport th_dport
#include "tcpip.def"
accept src=10.2.4.12 or dst=10.2.4.12;
Figure 47: monitorfilter.pf
The last line of monitorfilter.pf is your filter expression (or multiple expressions if you used multiple
–e expressions). The first four lines are defining src, dst, sport and dport. These are defined using
macros agin. This macros are defined in tcpip.def. The fifth line includes something called
“tcpip.def”.
As mentioned earlier INSPECT uses a C preprocessor. Therefore you can use C preprocessor directives
overall in your fw monitor scripts (on the command line as well as in files).

Revision: 1.01
src for example is defined as ip_src. ip_src is defined as [12, b] in the included tcpip.def.
tcpip.def can be found in $FWDIR/lib and is a very good resource for useful definitions. You can
include other files in $FWDIR/lib as well if you like.
If you use fw monitor you can create your own “library” and include it (e.g. using the –f option). This
allows you to define your own definitions of commands and expressions you are using on a regular basis.
Take a look at Useful macros in tcpip.def for a collection of useful expressions.
Please note that predefined macros (like src, dport, sport …) are only automatically defined if
! you are using expressions on the command line. If you are using files or standard input for providing
filter expressions you have to define the macros for yourself or include them using the #include
directive manually.

Revision: 1.01
Useful macros in tcpip.def
Macro Example Description

ip_p ip_p = PROTO_icmp IP protocol
ip_len ip_len > 128 Length of the IP packet
ip_ttl ip_ttl < 31 Time to live
ip_src ip_src = 172.16.4.3 Source IP address
ip_dst ip_dst = 10.2.4.12 Destination IP address
th_sport th_sport > 1024 TCP source port
th_dport th_dport = 80 TCP destination port
th_seq th_seq > 54245 TCP sequence number
th_ack th_ack < 349274 TCP acknowledged number
th_flags th_flags = (TH_SYN & TH_ACK) TCP flags
uh_sport uh_sport > 1024 UDP source port
uh_dport uh_dport = 53 UDP destination port
icmp_type icmp_type = ICMP_UNREACH ICMP type
icmp_code icmp_code = ICMP_UNREACH_PORT ICMP code
! Please note that this is just a small amount of macros defined in tcpip.def. Take a look at
tcpip.def for yourself to find other useful expressions you may want to use.
Do not modify anything in tcpip.def or in any other *.def file in $FWDIR/lib by yourself. Check
! Point does not support any configuration with changed *.def files.
An exception are modifications done together with Check Point Support (according to a Service
Request) or found on SecureKnowldege.
More information about INSPECT
Refer to the Check Point Reference Guide for a complete overview about INSPECT. Reading the *.def
files in $FWDIR/lib will give you a good overview about the possibilities as well.

Revision: 1.01
Inspect fw monitor files
The recommended tool for analyzing fw monitor capture files is Ethereal (Using Ethereal to inspect fw
monitor files) or CPEthereal (Using CPEthereal to inspect fw monitor files). Nevertheless fw monitor
capture files can be inspected with every tool which is able to read the snoop file format (Snoop file
format (RFC 1761)).
Using snoop to inspect fw monitor files
snoop is a tool normally found on Sun Solaris machines. snoop allows you to capture packets and to
examine them. As described in Write output to file fw monitor writes its capture files in the file format
used by snoop. This allows us to use snoop to decode the files later on. This means you can generate
the fw monitor files on one machine and examine them on another machine using all of snoop’s
functions including verbose output and filtering.
! snoop is only available on Sun Solaris. For other platforms refer to Using tcpdump to inspect fw
monitor files or Using Ethereal to inspect fw monitor files.
The following example shows how an fw monitor capture file (two ICMP Echo Request and ICMP Echo
Replies, PreIn/PostIn and PreOut/PostOut) which was generated on a Linux machine is inspected on a
Sun:
bash-2.03# snoop -i fwmonitor.cap

1 0.00000 172.16.1.1 -> 172.16.1.2 ICMP Echo request (ID: 51470 Sequence number: 256)
3 0.00000 172.16.1.2 -> 172.16.1.1 ICMP Echo reply (ID: 51470 Sequence number: 256)
Figure 48: Inspecting fw monitor files with snoop

Revision: 1.01
bash-2.03# snoop -V -i fwmonitor.cap
________________________________
1 0.00000 172.16.1.1 -> 172.16.1.2 ETHER Type=0800 (IP), size = 98 bytes
1 0.00000 172.16.1.1 -> 172.16.1.2 IP D=172.16.1.2 S=172.16.1.1 LEN=84, ID=47628
________________________________
2 0.00000 172.16.1.1 -> 172.16.1.2 IP D=172.16.1.2 S=172.16.1.1 LEN=84, ID=47628
________________________________
3 0.00000 172.16.1.2 -> 172.16.1.1 IP D=172.16.1.1 S=172.16.1.2 LEN=84, ID=4875
________________________________
4 0.00000 172.16.1.2 -> 172.16.1.1 IP D=172.16.1.1 S=172.16.1.2 LEN=84, ID=4875
________________________________
5 0.00000 172.16.1.1 -> 172.16.1.2 IP D=172.16.1.2 S=172.16.1.1 LEN=84, ID=47629
________________________________
6 0.00000 172.16.1.1 -> 172.16.1.2 IP D=172.16.1.2 S=172.16.1.1 LEN=84, ID=47629
________________________________
7 0.00000 172.16.1.2 -> 172.16.1.1 IP D=172.16.1.1 S=172.16.1.2 LEN=84, ID=4876
________________________________
8 0.00000 172.16.1.2 -> 172.16.1.1 IP D=172.16.1.1 S=172.16.1.2 LEN=84, ID=4876
Figure 49: Inspecting fw monitor files with snoop – summary output

Revision: 1.01
bash-2.03# snoop -v -c 1 -i fwmonitor.cap
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 1 arrived at 8:26:43.00
ETHER: Packet size = 98 bytes
ETHER: Destination = 69:31:65:74:68:30, (multicast)
ETHER: Source = 0:0:0:0:0:0,
ETHER: Ethertype = 0800 (IP)
ETHER:
IP: ----- IP Header -----
IP:
IP: Version = 4
IP: Header length = 20 bytes
IP: Type of service = 0x00
IP: xxx. .... = 0 (precedence)
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: Total length = 84 bytes
IP: Identification = 47628
IP: Flags = 0x4
IP: .1.. .... = do not fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 64 seconds/hops
IP: Protocol = 1 (ICMP)
IP: Header checksum = 2679
IP: Source address = 172.16.1.1, 172.16.1.1
IP: Destination address = 172.16.1.2, 172.16.1.2
IP: No options
IP:
ICMP: ----- ICMP Header -----
ICMP:
ICMP: Type = 8 (Echo request)
ICMP: Code = 0 (ID: 51470 Sequence number: 256)
ICMP: Checksum = 2be5
ICMP:
1 packets captured
bash-2.03#
Figure 50: Inspecting fw monitor files with snoop – verbose output
Especially when working in verbose mode (-v) it is recommended to display only a few packets.
! Use –c to limit the number of packets or use filter expressions. snoop filter expressions are not
discussed in this paper. Refer to the snoop man page for further information.
! This paper does not cover advanced snoop usage including things like filtering, converting etc. You
can find further information at The Secrets of Snoop.

Revision: 1.01
Using tcpdump to inspect fw monitor files
tcpdump has a similar functionality like snoop. Compared to snoop it runs on many platforms including
Linux, IPSO, FreeBSD …. tcpdump uses a slightly different file format than snoop. Therefore it is not
possible to open fw monitor files with tcpdump directly:
brain:/home/udos # tcpdump -r fwmonitor.cap

tcpdump: bad dump file format
Figure 51: Inspecting fw monitor files with tcpdump – bad file format
This means we have to convert the fw monitor capture file to a file format which tcpdump is able to
read. One possibility is to use editcap (see editcap for further information). editcap is a tool from the
Ethereal package which is able to convert between different capture file formats. By default editcap
converts any input file to an output file in tcpdump format (tcpdump actually uses the libpcap file format.
Visit the tcpdump/libpcap homepage for further information).
brain:/home/udos # editcap fwmonitor.cap tcpdump.cap

Figure 52: editcap – Converting from snoop file format to tcpdump (libpcap) file format
This will give you a capture file named tcpdump.cap with the same content as fwmonitor.cap which
can be read by tcpdump:
brain:/home/udos # tcpdump -r tcpdump.cap

08:26:43.000000 172.16.1.1 > 172.16.1.2: icmp: echo request (DF)
08:26:43.000000 172.16.1.2 > 172.16.1.1: icmp: echo reply
08:26:43.000000 172.16.1.2 > 172.16.1.1: icmp: echo reply
08:26:43.000000 172.16.1.2 > 172.16.1.1: icmp: echo reply
08:26:43.000000 172.16.1.2 > 172.16.1.1: icmp: echo reply
Figure 53: Inspecting fw monitor files with tcpdump – summary output
Like snoop, tcpdump offers the possibility to output the data in an even more detailed was. This can be
achieved by using verbose options. tcpdump offers three verbose options – -v, -vv and –vvv – with
different verbose levels:
brain:/home/udos # tcpdump -v -r tcpdump.cap

08:26:43.000000 172.16.1.1 > 172.16.1.2: icmp: echo request (DF) (ttl 64, id 47628, len 84)
08:26:43.000000 172.16.1.2 > 172.16.1.1: icmp: echo reply (ttl 255, id 4875, len 84)
Figure 54: Inspecting fw monitor files with tcpdump – verbose output
! This paper does not cover advanced tcpdump usage including things like filtering, converting etc.
You can find further information at tcpdump man page.

Revision: 1.01
Using Ethereal to inspect fw monitor files
Basic Ethereal usage
Ethereal is a graphical tool to analyze and capture network traffic. Ethereal is available on a wide range of
platforms and operating systems including all major UNIX flavors (Solaris, Linux, *BSD …), Windows
(Windows 9x, ME, NT 4, 2000 and XP), Mac OS X and many more. The screenshots in this paper were
taken on a Linux machine (for Ethereal). Ethereal reads a wide variety of capture formats including the
format used by fw monitor (which is in fact the same format as snoop). This means you can simply
open a fw monitor file in Ethereal:
Figure 55: Ethereal – main window

Revision: 1.01
The Ethereal main window consists of three panes. The top pane lists all packets in the opened file. This
overview pane lists information like capture time, source- and destination address together with a short
(protocol dependent) information:
Figure 56: Ethereal – overview pane

Revision: 1.01
The pane in the middle shows protocol specific decodes of the different packet layers. This decode pane
uses a tree view to display the different protocol values:
Figure 57: Ethereal – decode pane

Revision: 1.01
The bottom pane displays the raw packets’ data. This raw data pane highlights parts according to the
selection in the decode pane:
Figure 58: Ethereal – raw data pane
As you can see, Ethereal displays four “lines” per packet (preIn, postIn, preOut and postOut). Please not
that depending on the –m and/or –p switches there might be more or less lines per packet. The
information about the direction and the interface is not visible at first. This information is “hidden” in the
MAC addresses:
Figure 59: Ethereal – direction and interface as MAC address

Revision: 1.01
Ethereal fw monitor additions
Alfred Köbler (Alfred.Koebler@icon.de) wrote an addition to Ethereal which enables Ethereal to display
not MAC addresses but the fw monitor information. This addition is part of the standard Ethereal
distribution since version 0.9.9. It can be activated using Edit/Preferences/Protocols/Ethernet/Interpret
as FireWall-1 monitor file:
Figure 60: Ethereal – activate fw monitor decoding

Revision: 1.01
If the fw monitor decoding is activated, Ethereal will display the decoded fw monitor information in
the MAC addresses instead of the MAC addresses itself. It will show the direction ( i - preIn, I - postIn, o
- preOut or O - postOut) and the interface:
Figure 61: Ethereal – fw monitor decoding
The summary line (which can also be displayed as an additional column in the overview pane) lists all
encountered interfaces and the packet’s direction. For a packet entering the gateway through eth0 and
leaving the gateway through eth1 the summary line will show:
Interface Direction Summary line

eth0 i - preIn i eth1 eth0
eth0 I - postIn eth1 I eth0
eth1 o - preOut eth1 eth0 o
eth1 O - postOut eth1 O eth0

Revision: 1.01
Activate the FW-1 chain column
The interface and direction information described above can also be displayed as an additional column in
the overview pane. To activate the chain column go to Edit/Preferences/Protocols/Columns and add a
new column like showed below:
Figure 62: Ethereal – activate FW-1 direction/interface column

Revision: 1.01
This will give you an additional column which displays the interface and direction information:
Figure 63: Ethereal – FW-1 direction/interface column

Revision: 1.01
Using display and color filters on fw monitor parameters
Ethereal offers the possibility to display only specific packets and/or to display them with different colors.
The easiest way to display only specific packets is to select a packet in the overview pane and select
Follow TCP Stream from the context menu. This will automatically set a display filter to only display
packets of this specific connection (based on source/destination IP addresses and ports). You can see
this filter below the raw data pane. Additionally it displays the data exchanged between client and server
in a separate dialog box:
Figure 64: Ethereal – Follow TCP Stream
The display filter in this case is:
(ip.addr eq 10.2.4.12 and ip.addr eq 172.16.1.1) and (tcp.port eq 41748 and tcp.port eq 80)
Figure 65: Ethereal – TCP Stream display filter example
Please note that this filter only uses IP addresses and ports. Therefore you will still have all four
! lines per packet in the overview pane. An exception might be if you are using NAT (where the
addresses might change inbound and/or outbound) or if you used capture masks (Capture masks)
while creating the capture file.
Revision: 1.01
Another possibility is to select a value in the decode pane and select Match or Prepare together with an
logical operator. This is especially useful to discover how the property is called and which data types it
accepts:
Figure 66: Ethereal – Match selected property
The filter above would only list packets in the overview pane which where captured postOut (outbound
interface, after the VM).

Revision: 1.01
Other useful expressions are:
Field Property Value

IP address (source or destination) ip.addr IP address
Source IP address ip.src IP address
Destination IP address ip.dst IP Address
TCP port (source or destination) tcp.port Port number (0-65535)
TCP source port tcp.srcport Port number (0-65535)
TCP destination port tcp.dstport Port number (0-65535)
UDP port (source or destination) udp.port Port number (0-65535)
UDP source port udp.srcport Port number (0-65535)
UDP destination port udp.dstport Port number (0-65535)
fw monitor direction fw1.direction “i”, “I”, “o” or “O”
fw monitor interface fw1.interface An Interface name (e.g. “eth0”)
Figure 67: Ethereal – Useful filter properties
Ethereal filters require no special syntax to check whether an IP address belongs to a specific
subnet. Instead you can use an IP address with Classless Inter Domain Routing (CIDR) notation
! (e.g. 192.168.10.26/24) anywhere instead of a normal IP address. To check whether a packet is

sent from or sent to a specific network (192.168.10.26/24) you can use the following filter:
ip.addr eq 192.168.10.26/24
You can find a list with all known properties under Help/Help/Display Filters.

Revision: 1.01
In addition Ethereal offers the possibility to colorize packets according to filters. The syntax used there is
the same like the syntax for the display filters. You can add color filters using Display/Colorize
Display…. A simple color filter is to colorize packets according to their interface direction:
Figure 68: Ethereal – Color Filters

Revision: 1.01
Using CPEthereal to inspect fw monitor files
Based on the standard Ethereal Pedro Paixão and Shaul Eizikovich created an enhanced version of
Ethereal. This “Check Point flavor of Ethereal” (reference as CPEthereal on the following pages) extends
the standard Ethereal in many areas to cover Check Point (an fw monitor) specific needs and
functions. CPEthereal is available in two versions. A public version with slightly improved fw monitor
decoding (public CPEthereal) and a enhanced CSP version with all the features covered below (CSP
Ethereal).
Block coloring
Because fw monitor may capture multiple samples of the same packet passing through the firewall it is
sometimes hard to differentiate between the different packets. CPEthereal can group samples of the
same packets by colorizing them. This can be activated using CheckPoint/Colorize:
Figure 69: CPEthereal – activate Block coloring

Revision: 1.01
Once activated CPEthereal will colorize samples of the same packets in blue and red like the example
below:
Figure 70: CPEthereal – Active Block coloring

Revision: 1.01
NAT Highlighting
Following a connection through the firewall can be simplified by using Display Filters (refer to Using
display and color filters on fw monitor parameters). However, once you are using NAT things might get
more complicated. To simplify this task CPEthereal recognizes NATted packets and marks them red in
the overview pane. Additionally it provides some more information about the NAT type in the decode
pane:
Figure 71: CPEthereal – NAT Highlighting

Revision: 1.01
Improved FTP decomposing and search mechanism
Many environments have problems with malformed FTP transfers. Although not directly Check Point
related, CPEthereal provides enhanced FTP features.
First of all CPEthereal provides a more detailed FTP control connection decomposing than the standard
Ethereal. This includes things like an explicit test for an ending <CR><LF> and a decoding and counting
of replied lines (banners in most cases):
Figure 72: CPEthereal – FTP decomposing

Revision: 1.01
Because some problems (missing <CR><LF> at the end, too long banner) are not uncommon
CPEthereal also provides a function for searching such problematic packets using CheckPoint/FTP:
Figure 73: CPEthereal – FTP search

Revision: 1.01
Check Point enhanced search
Using CheckPoint/Find… it is possible to search packets according to their Check Point specific
properties:
Figure 74: CPEthereal – Check Point enhanced search
The Check Point enhanced search dialog consists of three search areas.
The top area allows you to find packets based on connection properties:
‚ NAT: Find packets which where NATed
‚ SEQT Find packets where the sequence number or the acknowledge number was changes
‚ UUID: Find packets belonging to specific connection based on their UUID
The pane in the middle allow you to filter the packets based on their capture position in the chain.
In addition it’s possible to specify additional restrictions using Ethereal filters (refer to Using display and
color filters on fw monitor parameters for an overview about Ethereal filter syntax) in the bottom pane.
Please note that the chain positions in the enhanced search do only make sense for capture files
! captured with NG with Application Intelligence (FP4) or higher. This feature requires absolute chain
positions (Use absolute chain positions [-a]) which are only available since NG with Application
Intelligence.

Revision: 1.01
Block Filters
Block filters allow you to find packet blocks (see Block coloring for further details) based on specific
packet chain positions based or absent in these blocks. It’s also possible to additionally specifiy an
Ethereal filter (refer to Using display and color filters on fw monitor parameters for an overview about
Ethereal filter syntax):
Figure 75: CPEthereal – Block Filter

Revision: 1.01
Tracking UUIDs and chain positions
Since FP3 fw monitor is able to write the connection UUID to the capture file (Using UUIDs and
SSIDs). First of all CPEthereal is able to display the UUID in the decode pane. Additionally it’s possible to
follow a connection based on the UUID. Select a packet of a connection you’re interested in and choose
CheckPoint/Track UUID. This will show you only packets with the same UUID like the UUID of the
selected packet:
Figure 76: CPEthereal – Track UUID

Revision: 1.01
A new feature in NG with Application Intelligence (FP4) is fw monitor’s ability to write absolute chain
IDs (Use absolute chain positions [-a]) to the capture files rather than relative chain Ids which do only
make sense with the corresponding fw ctl chain output. CPEthereal knows the absolute chain Ids
used by fw monitor and is therefore able to display the mnemonic for the chain position as additional
information in the FW-1 chain column and in the decode pane:
Figure 77: CPEthereal – display absolute FW-1 chain positions
Additional fw monitor header properties
CPEthereal includes an improved fw monitor decoding. This includes the possibility to use display or
color filters on additional packet properties:
Field Property Value

fw monitor direction fw1.direction “i”, “I”, “o” or “O”
fw monitor interface fw1.interface An Interface name (e.g. “eth0”)
fw monitor connection uuid/suid fw1.uuid 32bit integer
fw monitor chain module fw1.chain Chain module alias name
fw monitor NAT mode fw1.nat “HIDE”, “STATIC_SRC” or “STATIC_DST”
Figure 78: CPEthereal – Useful filter properties

Revision: 1.01
srfw – fw monitor on the client side
SecuRemote/SecureClient since Feature Pack 3 includes an utility named “srfw” which provides some
functionality of the fw command on the client side. One functionality is to capture packets on the client
side with srfw monitor like it is possible on the gateway side with fw monitor. The binary
(srfw.exe) is located under $SRDIR\bin (normally C:\Program
Files\CheckPoint\SecuRemote\bin). The general syntax is:
srfw monitor [-d] <{-e expr}+ | -f <filterfile | ->> [-l len] [-m mask]
[-x offset[,length]] [-o file]
Figure 79: srfw monitor syntax
The usage of srfw monitor (e.g. the Break Sequence) and the options are the same as the fw
monitor options.
Figure 80: srfw monitor example – four ICMP echo requests/replies on a german Windows XP
Please note that although srfw monitor understands most of the fw monitor command line
! switches not every switch is implemented. You can use some switches (e.g. –e and –f) with srfw
monitor (srfw monitor isn’t even complaining about it!), but they simply perform no actual
function. But this can change in future versions of SecuRemote/SecureClient.

Revision: 1.01
fw monitor on FireWall-1 VSX
If you are using FireWall-1 VSX you have multiple virtual routers and firewalls on one physical machine.
Each router and each firewall has it’s own IP stack and also it’s own kernel module chain. On a VSX
module each firewall command has the ability to specify on which VS (virtual System) this command
should be executed. Each VS has a name and number. You can find out this number using fw vsx
stat:
#fw vsx stat -v

VSX Status Report
=================
Number of Virtual Systems allowed by license: 100
Customer Virtual Systems active / configured: 9 / 9
Virtual Routers active / configured: 1 / 1
Management Virtual Systems active / configured: 1 / 1
VSID |VRID | Type & Name | Main IP | Policy Name | SIC Stat
-----+-----+-------------------+---------------+-----------------+---------
0 | 0 | M noor | 194.29.37.185| Standard | Trust
6 | 6 | R noor-vr1 | 46.46.2.2| InitialPolicy | No Trust
13 | 13 | S noor_vs_7 | 46.46.11.11| Standard | Trust
22 | 22 | S noor_vs_6 | 46.46.10.10| Standard | Trust
Type: M - Management VS, R - Virtual Router, S - Virtual System.
Total of 11 Virtual Systems
Figure 81: fw vsx stat example
fw monitor, when used with –vs option, monitors Virtual System traffic. It does not show any traffic
passing through Virtual Routers.
fw monitor –vs <vsid or vs name>

Figure 82: fw monitor on FireWall-1 VSX
! fw monitor on a Virtual Router will only show packets which are inspected by the Virtual Router
(which are packet which are targeted to the Virtual Router’s virtual IP stack only).

Revision: 1.01
Resources
Secure Knowledge Links
What is "fw monitor"?

https://support.checkpoint.com/csp/idsearch.jsp?resultStart=1&id=10022.0.1862922.2481845
Syntax examples for using the fw monitor command

https://support.checkpoint.com/csp/idsearch.jsp?id=sk1062
How to run the "fw monitor" command in FireWall-1 4.0 SP3 and above and FireWall-1 4.1
How to view the 'fw monitor' output file!

https://support.checkpoint.com/csp/idsearch.jsp?resultStart=1&id=sk3474
How does NG handle TCP connections

What license feature is needed to run the command "fw monitor" on a VPN-1/FireWall-1 module?
Can the fw monitor utility run during FireWall-1 Policy installation?

https://support.checkpoint.com/csp/idsearch.jsp?resultStart=1&id=skI4444
How to prevent the error "/opt/CPfw1-41/tmp/monitorfilter.pf" when running fw monitor?

How to avoid the error: "Failed to Load Security Policy: Bad file number"
Error when running 'fw monitor' command: "unknown interface (255): Interrupted system call"
What to do if FTP data suddenly stops working.


Revision: 1.01
Detecting sniffers on your network
http://www.securiteam.com/unixfocus/Detecting_sniffers_on_your_network.html
snoop
snoop vulnerable to a remotely exploitable buffer overflow

http://www.securiteam.com/exploits/3B5PQRPQAO.html
The Secrets of Snoop

http://www.spitzner.net/snoop.html
snoop man page

Use man snoop to see the snoop manual page. An online copy is available at
http://www.uwsg.iu.edu/usail/man/solaris/snoop.1.html
Snoop file format (RFC 1761)

http://www.ietf.org/rfc/rfc1761.txt?number=1761
tcpdump
tcpdump/libpcap homepage
http://www.tcpdump.org/
tcpdump man page

Use man tcpdump to see the tcpdump manual page. An online copy is available at
http://www.tcpdump.org/tcpdump_man.html
Ethereal
Ethereal homepage
http://www.ethereal.com/
Ethereal user guide

http://www.ethereal.com/docs/user-guide/
editcap
http://www.ethereal.com/editcap.1.html
Ethereal fw monitor additions

http://www.ethereal.com/lists/ethereal-dev/200206/msg00290.html

Revision: 1.01
CPEthereal
Public Version
http://www.checkpoint.com/techsupport/csp/downloads.html - cpethereal
CSP Version
http://www.checkpoint.com/techsupport/downloadsng/utilities.html - CPethereal
Miscellaneous
An Essay on Endian Order

http://www.cs.umass.edu/~verts/cs32/endian.html

Revision: 1.01
Reference
Multicast MAC addresses
Some tools are not able to decode fw monitor Layer 2 header information properly. fw monitor
stores it’s own information in the header fields designed for MAC addresses (Refer to fw monitor file
format). This can be misinterpreted in some cases as Multicast MAC addresses.
fw monitor file format
Although fw monitor capture files are using the snoop file format the content is slightly different. fw
monitor does not write down MAC addresses (12 bytes; 6 per MAC address) in the Layer 2 Frame
header. Instead fw monitor writes down information about the interface and chain position where the
packet was captured.
If you do not use the –u or –s option or an older version of fw monitor the fields for the MAC
addresses are used as follows:
Byte 0 1 2 3 4 5 6 7 8 9 10 11
snoop
Source MAC address Destination MAC address
file
fw Packet
chain
monitor direction Interface Name
positon
file (i/I/o/o)
If you are using –u or –s the fields are used as follows:
Byte 0 1 2 3 4 5 6 7 8 9 10 11
snoop
Source MAC address Destination MAC address
file
fw Packet
chain
monitor direction Interface Name UUID / SUUID
positon
file (i/I/o/o)

Revision: 1.01
UUID format
As described in Using UUIDs and SSIDs the firewall assigns a UUID to each connection passing through
it. This UUID is a 128 bit value built from four 32 bit value where only the first two are relevant.
1. UUID value Timestamp

2. UUID value A counter which is used if the first UUID value is not unique
3. UUID value The IP address of the local firewall (constant)
3. UUID value A PID (currently a constant, can be ignored).
Figure 83: UUID format
When using the –o option together with the –u or –s option, fw monitor does not write the full length
128 bit value to the capture file. Instead fw monitor writes down a stripped down 32 bit value. This
value is composed of the two least significant bytes of the second UUID value (counter) and the two least
significant bytes of the first UUID (timestamp).

Revision: 1.01
How To Configure
Templates for fw monitor
Technical Reference Guide
29 August 2011
© 2011 Check Point Software Technologies Ltd.
All rights reserved. This product and related documentation are protected by copyright and distributed under
licensing restricting their use, copying, distribution, and decompilation. No part of this product or related
documentation may be reproduced in any form or by any means without prior written authorization of Check
Point. While every precaution has been taken in the preparation of this book, Check Point assumes no
responsibility for errors or omissions. This publication and features described herein are subject to change
without notice.
RESTRICTED RIGHTS LEGEND:
Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph
(c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR
52.227-19.
TRADEMARKS:
Refer to the Copyright page (http://www.checkpoint.com/copyright.html) for a list of our trademarks.
Refer to the Third Party copyright notices (http://www.checkpoint.com/3rd_party_copyright.html) for a list of
relevant copyrights and third-party licenses.
Important Information
Latest Software
We recommend that you install the most recent software release to stay up-to-date with the latest functional
improvements, stability fixes, security enhancements and protection against new and evolving attacks.
Latest Documentation
The latest version of this document is at:
http://supportcontent.checkpoint.com/documentation_download?ID=12312
For additional technical information, visit the Check Point Support Center
(http://supportcenter.checkpoint.com).
Revision History
Date Description
29 August 2011 First release of this document
Feedback
Check Point is engaged in a continuous effort to improve its documentation.
Please help us by sending your comments
(mailto:cp_techpub_feedback@checkpoint.com?subject=Feedback on How To Configure Templates for fw
monitor Technical Reference Guide).
Contents
Important Information .............................................................................................3

How to Configure Templates FWMonitor ..............................................................5
Objective ............................................................................................................. 5
Supported Versions ............................................................................................. 5
Supported OS...................................................................................................... 5
Supported Appliances ......................................................................................... 5
Before You Start .....................................................................................................5
Related Documentation ....................................................................................... 5
Assumed Knowledge ........................................................................................... 6
Impact Environment and Warnings ...................................................................... 6
How fw monitor works ............................................................................................6
Using fw monitor ....................................................................................................7
Command Line fw monitor Switches .................................................................... 8
fw monitor Capture Masks .............................................................................. 9
fw monitor Filters ...........................................................................................10
Data Types ....................................................................................................10
Logical and Relational Operators ...................................................................10
Macros ...........................................................................................................11
Using fw monitor with the fw ctl Chain ................................................................11
Index ...................................................................................................................... 13
Objective
How to Configure Templates

FWMonitor
Objective
Inspecting network traffic through a Firewall is an essential part of deployment and troubleshooting tasks. fw
monitor is a powerful built-in tool by Check Point, used to simplify this task. fw monitor captures network
packets at multiple capture points within the Firewall through all interfaces simultaneously. This document
briefly describes how to use fw monitor and its features to simplify traffic capture through a firewall.
Supported Versions
Supported on all versions.
Supported OS
Supported on all OS platforms.
Supported Appliances
Supported on all appliances and open servers.
Before You Start

Related Documentation
sk41045 - fw monitor command
(https://supportcenter.checkpoint.com/supportcenter/portal?eventsubmit_dogoviewsolutiondetails=&solutioni
d=sk41045&js_peid=p-114a7ba5fd7-10001&partition=general&product=vsx, -
http://supportcontent.checkpoint.com/solutions?id=sk41045)
sk30583 - what is fw monitor
d=sk30583&js_peid=p-114a7ba5fd7-10001&partition=general&product=security -
sk41059 - How to interpret fw monitor output files in Wireshark
d=sk41059&js_peid=p-114a7ba5fd7-10001&partition=general&product=security -
sk33358 - Useful FW Monitor commands
d=sk33358&js_peid=p-114a7bc3b09-10006&partition=expert&product=security -
How to Configure Templates FWMonitor Page 5

Assumed Knowledge
Assumed Knowledge
· Working knowledge of network technology
· General knowledge of TCP / IP.
· General knowledge of packet flow through Check Point Gateway.
· General usage of packet protocol analyzers like snoop, tcpdump, Wireshark or Ethereal.
· General knowledge about Firewall chain modules + INSPECT filter.
Impact Environment and Warnings

The fw monitor command can cripple a Firewall that is already under heavy load. It is always best to test
packet captures during off peak times. If you are testing kernel drops, make sure to run them at the same
time, so you can reference packets in the drop file to the packet capture.
It is recommended to run the fw monitor command from a directory with plenty of space so that you do not
fill up the hard drive, such as /var or c:\temp.
How fw monitor works

In contrast to other capturing tools like snoop or tcpdump, fw monitor does not use the promiscuous mode
on network interface cards. Based on the fact that the Firewall already receives all packets (due to the
kernel module between the NIC driver and IP stack) fw monitor uses its own kernel module to capture
packets (compared to filtering/encrypting them).
Unlike snoop or tcpdump, fw monitor has the ability to capture packets at different positions in the FireWall-1
kernel module chain; snoop and tcpdump are capturing packets when they enter or leave the computer.
Especially when NAT is involved fw monitor offers the possibility to capture packets at multiple locations.
This can help you to see how the packets are translated by the firewall and on which IP address the routing
decision is made.
fw monitor is able to capture packets at four different positions in the Firewall: There are four inspection
points as a packet passes through the virtual machine
· on the inbound interface before the Virtual Machine (pre-inbound)
How fw monitor works Page 6

Impact Environment and Warnings
· on the inbound interface after the Virtual Machine (post-inbound)

· on the outbound interface before the Virtual Machine (pre-outbound)
· on the outbound interface after the Virtual Machine (post-outbound)
After fw monitor is executed, a specified INSPECT filter is compiled and loaded to the kernel. The fw monitor
filter is not to be confused with the filter used in a Policy. The fw monitor filter does not pass or drop any
packets, it only "watches" the packets as they pass through the kernel and displays them in the Command
Line Interface.
Using fw monitor
The easiest way to use fw monitor is to invoke it without any parameter. This will output every packet from
every interface that passes (or at least reaches) the enforcement module. Please note that the same packet
is appearing several times (two times in the example below). This is caused by fw monitor capturing the
packets at different capture points.
Break Sequence
Use ^C (that is Control + C) to stop fw monitor from capturing packets.
The above packet was captured on the first network interface (eth0) in inbound direction before the virtual
machine (lowercase i)
The second line tells us that this is an TCP payload inside the IP packet which was sent from port 1050 to
port 18190. The following element displays the TCP flags set (in this case PUSH and ACK). The last two
elements are showing the sequence number (seq=bf8bc98e) of the TCP packet and the acknowledged
sequence number (ack=941b05bc). You will see similar information for UDP packets.
You will only see a second line if the transport protocol used is known to fw monitor. Known protocols are for
example TCP, UDP and ICMP. If the transport protocol is unknown or cannot be analyzed because it is
encrypted (e.g. ESP or encapsulated (e.g. GRE) the second line will be missing.
Using fw monitor Page 7

Command Line fw monitor Switches

The syntax for fw monitor is:
fw monitor [-u|s] [-i] [-d] [-D] <{-e expr}+|-f <filter-file|->> [-l len] [-m mask] [-x offset[,len]] [-o <file>] <[-pi pos]
[-pI pos] [-po pos] [-pO pos] | -p all > [-a] [-ci count] [-co count] [-vs vsid or vsname]
Argument Explanation
-u|s Printing the UUID or the SUUID: The option –u or –s is used to print UUIDs or
SUUIDs for every packet. Please note that it is only possible to print the UUID or the
SUUID – not both.
-i Flushing the standard output: Use to make sure that captured data for each packet is
at once written to standard output. This is especially useful if you want to kill a running
fw monitor process and want to be sure that all data is written to a file.
[-d] [-D] Debugging fw monitor: The -d option is used to start fw monitor in debug mode. This
will give you an insight into fw monitor’s inner workings. This option is only rarely used
outside Check Point. It is also possible to use –D to create an even more verbose
output.
<{-e expr}+|-f <filter- Filtering fw monitor packets: fw monitor has the ability to capture only packets in
file|->> which you are interested. fw monitor filters use a subset of INSPECT to specify the
packets to be captured. Set the filter expression • on the command line using the –e
switch • by reading it from a file using the -f switch. • by reading it from standard input
using the -f - switch.
-l len Limiting the packet length: fw monitor allow you to limit the packet data which will be
read from the kernel with -l. This is especially useful if you have to debug high sensitive
communication. It allows you to capture only the headers of a packet (e.g. IP and TCP
header) while omitting the actual payload. Therefore you can debug the communication
without seeing the actual data transmitted. Another possibility is to keep the amount of
data low. If you don't need the actual payload for debugging you can decrease the file
site by omitting the payload. It’s also very useful to reduce packet loss on high-loaded
machines. fw monitor uses a buffer to transfer the packets from kernel to user space. If
you reduce the size of a single packet this buffer won’t fill up so fast.
m mask Setting capture masks: By default fw monitor captures packets before and after the
virtual machine in both directions. These positions can be changed. This option allows
you to specify in which of the four positions you are interested.
-x offset[,len] Printing packet/payload data: In addition to the IP and Transport header fw monitor
can also print the packets’ raw data using the –x option. Optionally it is also possible to
send all data that is written only to the screen the data written.
-o <file> Write output to file: Save the raw packet data to a file in a standard (RFC 1761)
format. The file can be examined using by tools like snoop, tcpdump or Ethereal. Note -
The snoop file format is normally used to store Layer 2 frames. For "normal" capture
files this means that the frame includes data like a source and a destination MAC
address. fw monitor operates in the firewall kernel and therefore has no access to Layer
2 information like MAC addresses. Instead of writing random MAC addresses, fw
monitor includes information like interface name, direction and chain position as "MAC
addresses".
-T Print time stamp in microseconds. -T is needed only when -o is not used. When -o is
used the exact time is written to the snoop file by default as of Corsica.

<[-pi pos] [-pI pos] Insert fw monitor chain module at a specific position: In addition to capture masks
[-po pos] [-pO pos] | (which give the ability to look at packets in a specific position) fw monitor has the ability
-p all > to define where exactly in the firewall chain the packets should be captured. This can
be defined using these options.
-a Use absolute chain positions: If you use fw monitor to output the capture into a file
(option –o), one of the fields written down to the capture file is the chain position of the
fw monitor chain module. Together with a simultaneous execution of fw ctl chain you
can determine where the packet was captured. Especially when using –p all you will
find the same packet captured multiples times at different chain positions. The option –a
changes the chain id from an relative value (which only makes sense with the matching
fw ctl chain output) to an absolute value. These absolute values are known to
CPEthereal and can be displayed by it.
[-ci count] [-co Capture a specific number of packets: fw monitor enables you to limit the number of
count] packets being captured. This is especially useful in situations where the firewall is
filtering high amounts of traffic. In such situations fw monitor may bind so many
resources (for writing to the console or to a file) that recognizing the break sequence
(Control-C) might take very long.
[-vs vsid or vsname] Capture on a specific Virtual Router or Virtual Machine: VPN-1 Power VSX enables
you to run multiple Virtual Routers and Firewalls on one physical machine. Using the
option –vs you can specify on which virtual component the packets should be captured.
This option is only available on a VPN-1 Power VSX module. Please refer to fw monitor
on FireWall-1 VSX for more information.
-h Displays the usage.
fw monitor Capture Masks

By default fw monitor captures packets at all four positions. With -m it is possible to capture packets at
specific positions. fw monitor uses single letters as indicators for the position:
Capture position fw monitor mask value
pre-inbound i (lowercase i)
post-inbound I (uppercase i)
pre-outbound o (lowercase o)
post-outbound O (uppercase o)
Using fw monitor masks it is easily possible to capture only packets before they are inspected by the firewall
in inbound direction and after they have been inspected by the firewall in outbound direction.
In the example below we are capturing traffic between a client (10.2.4.12) and a web server (172.16.1.1).
The client address is translated to 172.16.1.3 and the server address is translated to 10.2.253.2. You can
easily see how the non-translated packet enters the firewall and how the translated packet (source and
destination) is leaving the firewall:

Using the right combination of capture masks it’s very easy to find out when the firewall applies which NAT
rules (Hide NAT, Static Destination NAT or Static Source NAT). This is especially useful when you need to
know which packets the routing of the operating system is using to do the routing decision.
fw monitor Filters
fw monitor filters use a subset of INSPECT to specify the packets to be captured. The general syntax is the
accept expression:
"accept" in fw monitor filters does not mean that packets are actually accepted by the firewall. fw monitor
captures all packets which are accepted by the filter and discards the rest. A filter like accept; (capturing all
packets) will in no way change the behavior of the Firewall and its rule base.
The complexity of an expression can vary from a simple test (checking for a specific value at a specific
offset) to a complex expression using different checks and logical operators.
Data Types
INSPECT knows several native data types. Just some of them are useful for fw monitor:
Hexadecimal Integers A number beginning with 0x e.g. 0x5ab4
Octal Integers A Number beginning with 0 e.g. 0777
Decimal Integers Any other number e.g. 23
IP Address Four decimal integers separated by three periods e.g. 172.45.2.4
Logical and Relational Operators

In addition to the single expressions testing for equality, you can combine different expressions using
several logical and relational operators.
< Less than
> Greater than

Using fw monitor with the fw ctl Chain
<= Less than or equal to
>= Greater than or equal to
= or is Equal
!= or is not Not equal
, Logical AND
or Logical Or
xor Logical XOR
not Logcial NOT
Macros
fw monitor offers an more intuitive way of specifying the desired field:
Field Macro Expression
source address src [12:4,b]
destination address dst [16:4,b]
source port sport [20:2,b]
destination port dport [22:2,b]
Using these macros it very easy to define filters. Here are some examples:
Captures everything except http traffic. #fw "accept not ( sport=80 or dport=80);"
All TCP packets sent between host #fw monitor "accept [9:1]=9 , ((src=10.2.4.12 ,
10.2.4.12 and 172.16.1.2 dst=172.16.1.2) or (src=172.16.1.2 , dst=10.2.4.12));"
Captures all traffic from and to the host #fw monitor –e "accept src=172.29.109.1 or
172.29.109.1 dst=172.29.109.1;"
Captures all http traffic on port 80 only #fw monitor –e "accept dport==80;"
rd
3 filter will capture only inbound direction
before and after the virtual machine (i and #fw monitor –m iI –e "accept;" –o monitor.out
I), and redirects the output to a file.

Check Point uses a "kernel module chain" for different kernel modules which are working with the packets.

You can see the actual chain using the fw ctl chain command. This shows you the chain modules actually
loaded on your machine and their order. fw monitor can be inserted in any position in the chain. Note that
there are more kernel modules in the chain which are not visible by fw ctl chain and which cannot be used
for fw monitor kernel module positioning.
The output of fw ctl chain is platform, version and product dependent. There is no reason to worry if your fw
ctl chain output looks different to the above. The number and kind of modules displayed here may vary
based on the platform used and products installed.
fw monitor inserts its own modules in this module chain and captures packets. By default this is not the first
and last position in the chain. Therefore the original meaning of before and after needs to be redefined.

Index
A
Assumed Knowledge • 6
B
Before You Start • 5
C
Command Line fw monitor Switches • 8
D
Data Types • 10
F
fw monitor Capture Masks • 9
fw monitor Filters • 10
H
How fw monitor works • 6
How to Configure Templates FWMonitor • 5
I
Impact Environment and Warnings • 6
Important Information • 3
L
Logical and Relational Operators • 10
M
Macros • 11
O
Objective • 5
R
Related Documentation • 5
S
Supported Appliances • 5
Supported OS • 5
Supported Versions • 5
U
Using fw monitor • 7
Using fw monitor with the fw ctl Chain • 11
Introduction ........................................................................................................................................... 2
User Process Core Dumps ................................................................................................................. 2
Kernel Panic Core Dumps .................................................................................................................. 2
The Debugger ..................................................................................................................................... 2
What is KDB?...................................................................................................................................... 3
Manually Opening a Core File on Unix Machines (User Process) ................................................... 4

Special Notes for Solaris Platforms .................................................................................................... 4
Using a Windows Dump File (User Process) ..................................................................................... 6

Getting a Dump File from the Customer............................................................................................. 6
Installing WinDbg Debugging Tool ..................................................................................................... 6
Debugging a Windows Executable ..................................................................................................... 7
Preparations ................................................................................................................................... 7
Getting Started ............................................................................................................................... 7
Displaying the Stack ....................................................................................................................... 7
Kernel Panic on Linux Based Machines (SPLAT).............................................................................. 9

For R55 Version and Below................................................................................................................ 9
For NGX Version and Above .............................................................................................................. 9
Entering KDM Mode on Linux (Freeze) .............................................................................................. 9
Kernel Panic on Solaris Based Machines......................................................................................... 11

Opening Kernel Panic on Solaris Machines ..................................................................................... 11
Entering the KDM Mode on Solaris (Freeze).................................................................................... 11
Kernel Panic on IPSO Based Machines ............................................................................................ 12

Opening Kernel Panic on IPSO Based Machines. ........................................................................... 12
Basic Analysis of the Kernel on an IPSO Machine........................................................................... 13
Entering the KDB Mode on IPSO Machines (Freeze) ...................................................................... 14
Appendix .............................................................................................................................................. 15
How to Determine if the Kernel Module on Solaris is 32 or 64 Bit.................................................... 15
Core Files Locations on the Different Platforms ............................................................................... 15
SPLAT/Linux................................................................................................................................. 15
Solaris........................................................................................................................................... 15
IPSO ............................................................................................................................................. 16
What to do with the Extracted Stack................................................................................................. 16
Which Debugger Should be Used for which OS?............................................................................. 17
Solaris Kernel Panic example........................................................................................................... 18
Kernel Panic on Splat\Linux.............................................................................................................. 19
1 ©2009 Check Point Software Technologies Ltd. All rights reserved.
Classification: [Unrestricted]—For everyone

Introduction
There are two types of core files: user process and kernel panic.
User Process Core Dumps

The user process core dump is a core file created by the operating system for a process
which is terminated because the operating system received certain signals. A core file is a
disk copy of the contents of the process address space when the process received the
terminate signal. The file also contains additional information about the state of the
process, which can be used by a debugger. Usually a bug in the application causes an
abnormal termination of a process, which then produces a core file.
Kernel Panic Core Dumps

The crash dump or kernel panic is a core file created by the operating system when there
is a fatal system error. The crash dump is a disk copy of the physical memory of the
computer during a fatal system error. A message that describes the error is printed to the
console and the operating system then generates a crash dump. The contents of physical
memory are written to a predetermined dump device, which is generally a local disk
partition. After the crash dump has been written to the dump device, the system then
reboots. Fatal operating system errors can be caused by: bugs in the operating system,
associated device drivers and loadable modules, or by faulty hardware.
A user process core dump can result in a variable size file - fwd process, which may only
show 28 MB of RAM. Whereas a kernel panic is dumped into a file which is the size of the
machine's total available RAM.
You can use a core file to analyze the memory state at the time the crash occurred. A
debugger generates a file that holds a representation of a stack from the memory which is
populated with function names and addresses.
The stack that is generated is read in an LIFO (Last In, First Out) style. The top most
function represented in the stack is last function running in the memory before the crash
occurred.
The Debugger
The debugger reads symbols from "symbol files" which contain: names of variables,
functions, and types (i.e. C language structures). The information in these files is inherent
to the text of the program and does not change as it executes. When you debug a
program, the debugger finds the appropriate symbol table to translate the data that is in the
core file. Symbol tables only contain the memory addresses of the symbols, but not the
variables and functions names. For example, we use function names like main(), whereas
computers use addresses like 0x804b64d or 0xbffff784.
The program's code is also compiled with debugging information (what we call the
"Unstripped version") which tells the debugger two things:

̇ How to associate the address of a symbol with its name in the source code.
̇ How to associate the address of a machine code with a line of source code.
Each time a program performs a function call, information about that call is generated. That
information includes: the location of the call in the program, the arguments of the call, and
the local variables of the function being called. This information is saved in a block of data
called a stack frame. The stack frames are allocated in a region of memory called the call
stack.
What is KDB?
KDB is a machine's "kernel debugger" and the machine runs in a state similar to Windows
safe mode. We can use KDB to access the machines memory and look at the functions
that are running at a specific time for all the processes.

Manually Opening a Core File on Unix Machines (User
Process)
In order to extract the stack on a Unix machine, usually you need the "Unstripped version"
of the executable (ie. cpd) from the network. The "Unstripped version" is a version of an
executable or library (dll/lib) that holds all the symbols and debugging information.
To manually open a core file on a Unix machine:

1. Set up the exact same environment as the customer. – OS, Firewall-1 version and
HFA's.
2. Copy the core file to the intended machine.
3. Run these two commands:
# chmod 777 core_file - to set permissions to execute the file.
# file core_file – Generally this command indicates the executable responsible for
creating the core file ().
4. From the cpinfo extract the cphared (SVN foundation) build number and the fw1
build number.
a. Open the DLL/EXEC (View Picture) section of the cpinfo.
b. Search for the executable: fwd or cpd.
You should now have the build number of the specific executable responsible for the
crash.
5. Copy the "Unstripped version" of the executable and the libraries to the prepared
machine and put it in the appropriate directory. Contact Check Point Technical
Support in order to obtain the executables.
You can contact Worldwide Technical Assistance Centers at:
Americas: (972) 444-6600
International: +972-3-6115100
6. From the command line issue these commands:
# chmod 755 cpd - this command allows execute permissions to the firewall
executable that we have taken from the unstripped directory.
# touch core_file - the touch command updates the "last modified" date of the
file. This update is necessary, if the core file needs to be "touched" after the firewall
executable.
7. Use the debugger in the following manner:
# dbx executable core_file - this command gives you a prompt saying the debugger
is reading the symbols from the libraries.
The debugger finishes and prompts:
# dbx - type where and if the core file was read successfully this command
outputs the stack.
Special Notes for Solaris Platforms

If you see messages that are similar to the following:
dbx interface area seem to be corrupted in core file
(_DYNAMIC array longer than 15 entries)

(l@1) terminated by signal BUS (invalid address alignment)
dbx: core file read error: address 0 not in data space
And the command where returns you only one function:
(dbx) where
=>[1] _swtch(), at 0xef777cac
Then you should issue the following command to get the stack:
(dbx) lwps – will give failure location
o>l@1 signal SIGSEGV in strncmp()
l@2 LWP suspended in __signotifywait()
l@3 LWP suspended in ___lwp_cond_wait()
l@4 LWP suspended in _door_return()
Next issue the following command:
(dbx) lwp l@1
(l@1) stopped in strncmp at 0xef5a4a5c
strncmp+0x268: ld [%i1 + %i0], %i4
Now you can issue the where command to get the stack:
(dbx) where

Using a Windows Dump File (User Process)
Getting a Dump File from the Customer
The customer has to be prepared to produce a dump file before the application crashes.
Doctor Watson (drwtsn32) must be running on the customer's computer.
To prepare a Windows computer to create a dump file:
1. Open the Dr. Watson utility.
2. Confirm that Create Crash Dump File is checked:
Installing WinDbg Debugging Tool

To analyze the dump file that you received from the customer, you have to install WinDbg
Debugger.
You can download it from:

http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
During the installation, select the following options:
̇ Custom installation
̇ Debugging tools + Tools
After the file is installed, there is a new entry in your start menu: Debugging tools.
Note: You should install WinDbg in the directory D:\dbg.

Debugging a Windows Executable
Preparations
All of the data files must be located in one directory, for example: C:\data.
The input files are:
File Source information
FW.exe Contact Check Point Technical Support FW executable with debug information
FW.pdb Same as above FW intermediate file
FW.map Same as above FW map file
USER.dmp From the user Dump file

Americas: (972) 444-6600
Important: These files must comply with the Revision (Firewall-1 build) and the
encryption level (Non/Vpn/VpnDes etc.) of the customer’s product.
Getting Started
To debug a Windows executable:
1. Open a DOS window.
2. Change the directory to where the data files are: C:\data.
3. Confirm that you have installed WinDbg in directory D:\dbg, and then enter the
following command: D:\dbg\bin\windbg -z user.dmp .
4. The debugger prompts you for a DLL file – you should ignore it.
5. You are prompted for a source file. You may ignore it, or provide the exact path.
Note: The source must be of the same revision as the fw.exe that the customer has.
6. The source file is displayed with a yellow marker on the source code line where the
application crashed.
If the source code line is not displayed, then you have chosen the wrong source file.
You should repeat this procedure.
Displaying the Stack

You can display the call stack to show the sequence of function calls leading up to the
crash.

To display the call stack:
̇ Type ksnt.
The call stack should resemble the following:
# FramePtr RetAddr Function Name
00 000000000012f630 0000000000683b1f FW_STRONG!cmspipe_instance::GetMyEntrustCAObj+0x8(0x00F87270) [
fwcmspipe_table.cc @ 117 ]
01 000000000012fe3c 0000000000683ea8 FW_STRONG!cmspipe_instance::ReLogin+0xf(0x00F87270, 0x00000001) [
02 000000000012fe44 00000000005d1276 FW_STRONG!fwcms_CRLCache_timeout+0x28(0x00F87270) [
03 000000000012fe94 00000000005d3501 FW_STRONG!T_event_poll+0xd6(0x00F32258) [ events.c @ 853 ]
04 000000000012fea0 00000000005d3429 FW_STRONG!apply_socket_callbak+0x41(0x00F32258) [ events.c @ 3460 ]
05 000000000012feb8 00000000005d382d FW_STRONG!T_event_NT_mainloop+0x69(0x00F32258) [ events.c @ 3368 ]
06 000000000012fec8 00000000005d37f9 FW_STRONG!T_event_mainloop_e+0x2d(0x00F32258) [ events.c @ 3613 ]
07 000000000012fed0 00000000004f50ab FW_STRONG!T_event_mainloop+0x19(...) [ events.c @ 3600 ]
08 000000000012ff44 0000000000422a22 FW_STRONG!isakmpd_cmain+0x2db(0x00000001, 0x00F40804) [ fwisakmpd.c
@ 820 ]
09 000000000012ff60 000000000040151d FW_STRONG!cmain+0x302(...) [ fwmain.c @ 875 ]
0a 000000000012ff70 00000000006870bf FW_STRONG!main+0x2d(0x00000002, 0x00F40800) [ main.cc @ 85 ]
0b 000000000012ffc0 0000000077f1b304 FW_STRONG!mainCRTStartup+0xff
0c 000000000012fff0 0000000000000000 0x77f1b304
The first column signifies the Frame number. A frame with a higher number calls a
frame with a lower number. The crash is always in frame 0.
The next two columns are Frame pointer and Return address respectively.
The next column is read as follows:
Application!function+offset (function parameters) [Source file @
source line]

Kernel Panic on Linux Based Machines (SPLAT)
For R55 Version and Below
Linux currently has no available debugger for extracting the stack from a kernel panic
dump file. When a kernel panic occurs on a SPLAT/Linux machine the following files are
created in the /var/log/dump directory:
̇ The stack is often found in the file called analysis.

̇ If the stack can not be read in the analysis file:
a. Copy the file called dump.x to a Solaris machine.
b. Execute the following command on the Solaris machine: # strings -a >
stack.out.
c. Search for "<1> oops". The lines that follow should show the stack.
For NGX Version and Above

You must start the machine in debug mode (KDB) and then you can extract the stack.
To start the machine in debug mode (KDB):
1. Type Cpmodule#> echo 1 > /proc/sys/kernel/kdb . The machine freezes and
does not reply to pings, SSH, etc…
2. If you are connected via serial, press CTRL-A (^a) and the KDB prompt appears.
If you are directly connected, send a break signal (Pause/Break key). The machine
enters the KDB mode.
Entering KDM Mode on Linux (Freeze)

To extract the stacks from all CPUs on a frozen Linux machine:
1. For each CPU type:
a. cpu n - where <n> is the CPU number, starting from 0. For example: "cpu 0".
b. bt - After typing "bt", check which prompt is displayed.
For example, if you see "more>" (or any other prompt other than "kdb>"), then it
means there is more output and you must press Enter to see it.
Keep pressing Enter until you see the "kdb>" prompt.
c. rd - This command displays the registers for the current CPU.
2. Enter the following four commands after finishing step 1:
Note: These four commands are not CPU dependant.
a. md fw_prev_locker
(This command shows some internal data related to the lock mechanism.)
b. md irq_stat
(This command shows some IRQ handling statistics.)
c. lsmod
(This command shows the currently loaded drivers.)
d. dmesg

(This command displays the kernel messages that were buffered at the moment
of the freeze.)
Here too, keep pressing Enter until you see the "kdb>" prompt.

Kernel Panic on Solaris Based Machines
Opening Kernel Panic on Solaris Machines
When a kernel panic occurs on a Solaris platform there are a number of files that are
generated. The two files that are needed to extract the stack from the core are "vmcore.X"
and "unix.X". The first file contains the memory state at the time of the panic and the
second one contains the exact OS parameters (64/32 bit …) on which the panic occurred.
Note: You must use the same OS platform (Solaris8/9) as the machine that created
the core.
To open kernel panic on a Solaris machine:
1. From the command line type: adb -k unix.0 vmcore.0.
Note: In some cases you can receive an error that indicates that the panic occurred
on a 64 bit kernel instead of on a 32 bit kernel. If you receive this error
message, then follow this procedure.)
2. Type $<msgbuf.
3. Paste the value of sp and add $c after it. For example, if sp=61429720, you must
type 61429720$c.
4. Press Enter. The stack is displayed.
5. If the output resembles:
61429720$c
?()
data address not found
Do not use the sp value. Instead use the first fp (frame pointer).
This is an example of a Solaris kernel panic.
Entering the KDM Mode on Solaris (Freeze)

To create a crash dump on a frozen Solaris machine:
1. Run the dumpadm command. The following message should appear: Savecore
enabled: yes.
If this message does not appear, type dumpadm –y.
2. Use the dumpadm command to confirm that there is enough space in the savecore
directory. There should be at least twice the amount of the physical memory
available.
3. While hang occurs, send the break signal. The ok prompt appears.
If the kdb appears, enter the $q command.
4. At the ok prompt, enter the sync command. The machine crashes and creates a
crash dump.
5. Find the Unix.X and vmcore.x files. Continue with the, "To open kernel panic on a
Solaris based machine" procedure.

Kernel Panic on IPSO Based Machines
Opening Kernel Panic on IPSO Based Machines.
You should setup a lab environment that both the IPSO version and Firewall-1 version are
as similar as possible to the machine generating the panic.
To open kernel panic on an IPSO machine:
1. The following files are needed:
vmcore.nn – The crash file.
a. Created in /var/crash by IPSO after a crash.
b. The file is compressed and called vmcore.nn.gz. It should be uncompressed
with gunzip before being used.
kernel_g – The kernel symbols file.
a. IPSO creates a kernel symbols file, named kernel.nn.gz along with each
vmcore file. However this file is insufficient because it does not contain
debugging symbols.
As an alternative, there is a set of Nokia files which can be used instead. For
each IPSO version there is a special file called kernel_g, it can have a slightly
different name in some builds. Contact Check Point Technical Support in order
to obtain the Nokia files.
Americas: (972) 444-6600
Note: Ensure that you select your correct version and build.
b. The kernel_g file should be transferred to /var/crash on your IPSO machine.
c. If you have multiple IPSO images on the machine, you should keep all their
kernel_g files in /var/crash. Each file should have a distinct name (i.e.
kernel_g_ipso37 and kernel_g_ipso38).
fwmod.o – The firewall kernel module which has crashed.
a. Place the exacted file in /var/crash. You can also use a soft link.
b. This file can be found on the IPSO machine, you can search for it with the find
command.
Note: Confirm that you are using the correct the build number.
Other Check Point kernels.
a. If the crash occurred in another module, then you need the appropriate core
file. These files are identified by their module, for example: vpnmod.o. These
files are similar to the fwmod.o file.
b. Place the exact file in /var/crash. You can also use a soft link.
2. Open vmcore.nn the crash file.
a. Run gdb –k kernel_g vmcore.nn. The dump file is displayed without fw
symbols.
b. Load the fw symbols: add-symbol-file fwmod.o lkmods[0].area + 0x20 .

3. If you have core files for other Check Point modules, then you need to load the
appropriate symbols.
The add-symbol-file command requires that you have the name of the core file and
the serial number of the module.
a. Get the name of the appropriate core file for the Check Point module.
b. The serial number of the module is assigned according to the order in which the
modules are loaded.
Generally, vpn1 is 1 and fg is 2.
c. You can use id column of the modstat command to check the load order.
Note: Make sure that you use the modstat command on the same system.
Otherwise, the modules may have been loaded in a different order.
d. You can use the command p lkmods[id].private.lkm_any.lkm_name to
check the ids from within the dump file.
e. Use the command add-symbol-file kernel_name lkmods[id].area + 0x20
to load the symbols.
kernel_name is the name of the core file.
id is the serial number of the module.
4. Close the debugger with the q command.
Basic Analysis of the Kernel on an IPSO Machine

This section explains how to perform a basic analysis of the core file and the trap frame.
The trap frame contains the values of the registers at the time that the error happened.
To analyze the core file:
1. Use the bt command to display a stack trace.
2. The info frame n command gives more information for a specific stack frame.
3. You should examine the trap frame to determine if the crash is due to a CPU detected
error. An invalid memory access or division by zero produces a trap frame, but
intentional panic does not.
a. The following is an example of a trap frame that is seen when you print the
stack trace.
#20 0x9034f4f6 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1757498368,
tf_esi = -1774597504, tf_ebp = -1775309320, tf_isp = -1775309364,
tf_ebx = -1757011696, tf_edx = 1, tf_ecx = -1754091472, tf_eax = 0,
tf_trapno = 12, tf_err = 2, tf_eip = -1757011674, tf_cs = 8,
tf_eflags = 66178, tf_esp = -1764061692, tf_ss = -1809729458})
Note: Make sure the function name is trap, and not the similar syscall frame.
b. If there is more than one trap frame, then you should use the earliest one (the
last frame that was printed).
c. The most important register value is EIP, which is the instruction pointer. In the
above example the EIP value is listed as tf_eip = -1757011674. The value is
listed as a decimal which is incorrect for EIP.
d. The EIP value indicates that the crash occurred either at the line that EIP points
to, or the previous one. Print the commands from earlier bytes to inspect the
previous line.
Here is the previous line from the above trap frame example:

(kgdb) x/i -1757011674
0x97462126 <uri_try_set+22>: movl %edx,(%eax)
(kgdb) x/6i 0x97462126-0x10
0x97462116 <uri_try_set+6>: movl $0x0,0xfffffffc(%ebp)
0x9746211d <uri_try_set+13>: movl 0xfffffffc(%ebp),%eax
0x97462120 <uri_try_set+16>: movl 0x9772b030,%edx
0x97462126 <uri_try_set+22>: movl %edx,(%eax)
0x97462128 <uri_try_set+24>: leave
0x97462129 <uri_try_set+25>: ret
e. The lines that are marked in red are problematic. Only the second line
dereferences memory and that is the line which caused the crash.
Entering the KDB Mode on IPSO Machines (Freeze)

To create a crash dump on a frozen Solaris machine:
1. Send the break sequence to the console. From HyperTerminal:
CTRL-Pause/Break
NOTE: Nothing will be displayed on the console during this step.
NOTE: This will break any previously running sessions.
2. Type the ddb command and press Enter. IPSO is now in debugger mode.
3. Type db>t to obtain a trace. Print the stack to the terminal.
4. Capture this information and attach it to the case.
5. Type db>ps to obtain a list of processes and their associated states.
6. Type db>panic to force a panic. This command reboots the system and provides the
core file for analysis.
The core file is usually in the /var/crash directory. The file name is vmcore.x.gz (x
can be 1 or 2).

Appendix
How to Determine if the Kernel Module on Solaris is 32 or 64 Bit
The # isainfo – vk command shows the boot mode of the Solaris kernel (32/64 Bit).
To change from 32 bit kernel to 64 bit kernel:

̇ Enter these commands:
> booting the 64 bit kernel by default
#eeprom boot-file=/platform/sun4u/kernel/sparcv9/unix
To change from 64 bit kernel to 32 bit kernel:
̇ Enter these commands:
>booting the 32 bit kernel by default.
#eeprom boot-file=/platform/sun4u/kernel/unix
NOTE: You must verify that these modules exist in the machine. Otherwise the
machine cannot boot from the appropriate kernel module.
Core Files Locations on the Different Platforms

This section lists the different locations for core files on different platforms.
SPLAT/Linux
In SPLAT the core files are not located in the regular place, even if your core-dump-size is
defined to be "unlimited".
To show the location (and name pattern) of core files:
1. Type: cat /proc/sys/kernel/core_pattern .
2. The SPLAT output is:
/var/log/dump/usermode/%e.%p.core
3. The core files are located in /var/log/dump/usermode/.
%e.%p – combines the process name and pid to the name of the core file.
In other Linux systems, the content of the "core_pattern" file is usually just "core".
To enable core files generation by the OS:

1. Type the command: ulimit –c unlimited.
Refer to sk27392 for more information.
2. Add the following line to the /etc/sysctl.conf file:
kernel.core_uses_pid = 1
Solaris
This section gives examples of how to configure the settings for a core dump on a Solaris
machine.
To verify that the Solaris machine is enabled for core dump:
̇ Enter the following commands:

[daniela]/ > dumpadm
Dump content: kernel pages
Dump device: /dev/dsk/c1t0d0s1 (swap)
̇ The savecore directory for this machine is: /var/crash/daniela
To configure a Solaris machine to save the core dump:
̇ If the savecore value is set to no run, then enter the following command:
# dumpadm –y
To configure a Solaris machine to initiate a core dump during a crash:
̇ Use the coreadm command to configure conditions that initiate a core dump:
[daniela]/ > coreadm
global core file pattern:
init core file pattern: core
global core dumps: disabled
per-process core dumps: enabled
global setid core dumps: disabled
per-process setid core dumps: disabled
global core dump logging: disabled
Ensure that the value for per-process core dumps: is enabled. If this value is set
to disabled, use the following command:
coreadm –e process
IPSO
The location of the core dump files on an IPSO machine is: /var/crash. You must also
confirm that the IPSO machine can produce core files.
To confirm if the machine can produce core files:
1. Type the command: limit.
2. The following output is displayed:
cputime unlimited
filesize unlimited
datasize 262144 kbytes
stacksize 8192 kbytes
coredumpsize unlimited
memoryuse 122772 kbytes
memorylocked 81850 kbytes
maxproc 40
openfiles 64
3. If the value of coredumpsize is not "unlimited", then you should change the value.
Type the following command:
limit coredumpsize unlimited
What to do with the Extracted Stack

What should you do once the core file has been successfully opened and the stack can be
read? As mentioned earlier, the stack is LIFO style based (chronologically), which means
that the top most function written in the stack was the latest one to run. A function can be
called from many other functions - in order to narrow the possibilities for the crash the
context must be clear (i.e. the core file was created after policy installation).

Search all engines to find any CR's mentioning the functions found in the stack. Start with
the top most function in the stack and continue towards the bottom. Also, you should try to
crosscheck your search results with the functions found in the stack.
Which Debugger Should be Used for which OS?

If you are using a machine on Solaris or SPLAT/Linux platforms, you should contact Check
Point Technical Support in order to information about the debuggers.

Americas: (972) 444-6600
If you are using a machine on IPSO platform, use the built-in gdb debugger for both kernel
panic and user process core files.
For example, if the executable that caused the core file is cpd (verified issuing file
cpd.core command), you should find the build number of that executable.

Solaris Kernel Panic example
Here is an example of Solaris kernel panic:
[daniela]/sharon > adb -k unix.0 vmcore.0
physmem 3df6e
adb: warning: dump is from SunOS 5.9 Generic_118558-19; dcmds and
macros may not match kernel implementation
(Usually you can ignore this message.)
The adb debugger is waiting for information in the following format:
$<msgbuf
0x30001549522: pseudo-device: devinfo0
0x30001279623: devinfo0 is /pseudo/devinfo@0
0x300020d4d9f: NOTICE: bge2: link down (advertised capabilities changed)
0x300032d085f: NOTICE: bge2: link up 10Mbps Full-Duplex (forced)
0x300020b5020: /pci@1c,600000/scsi@2 (glm0):
Cmd (0x32bade0) dump for Target 0 Lun 0:
0x300020b9620: /pci@1c,600000/scsi@2 (glm0):
cdb=[ 0x2a 0x0 0x2 0x3 0x32 0xc0 0x0 0x1 0x0 0x0 ]
0x300020b49e0: /pci@1c,600000/scsi@2 (glm0):
pkt_flags=0x4000 pkt_statistics=0x60 pkt_state=0x7
0x300020b80e0: /pci@1c,600000/scsi@2 (glm0):
pkt_scbp=0x0 cmd_flags=0x1860
There are many lines of output, but we are only interested in the following:
0x30276d37660: sched:
0x30276d3e0e0: trap type = 0x31
0x300020b5de0: addr=0x3039168f617

0x3000036f660: pid=0, pc=0x781db6a8, sp=0x788e2c91, tstate=0x80001606,
context=0x0
0x30001c17520: g1-g7: 78bb6a20, 3029168f618, ffffffff, 781d9808, b, 10,
2a10004bd40
The phrase sp=0x788e2c91 is called the ‘Stack Pointer’ and is needed in order to get the
stack from the dump file.
Now issue 788e2c91$c at the command line and the following stack is displayed:
788e2c91$c
psv_spii_str_process_data+0x7d4(3000279cff8, 787924fc, 0, 2000, 0, 0)
fwtcpstr_add_packet+0xcc4(3000279cff8, 787924f4, 300026bbb50, 0, 78924a28,
300027250b0)
fwtcpstr_handle_packet+0x308(3000279cff8, 3000279d118, 788e3d4c, 788e3d48,
2, a46)
fw_conn_inspect+0x17c8(1c001, 3000279d12c, ffffffffffffffff, 0,
3000279d120, 3000279d124)
fw_filter_chain+0xde4(20000000, 7882db78, 86c00000, 50, 2a10004b9d8,
12ccb60)
fwchain_do_+0x698(3000279cff8, 0, 0, 787a5800, 787a5a18, 0)
fw_stack_call+0x1c(788e3701, 7812e274, 3000279cff8, 0, 0, 0)
fwstack_call+0x1a8(78796188, 7812e274, 3000279cff8, 0, 0, 0)
fwchain_do_ex+0x108(3000279cff8, 1, 0, 2a10004b720, 0, fffe)
fw_filter+0x400(30038dfdc80, 7, 0, 0, 2a10004b720, 3000157e550)
fwstrmod_filter+0x434(3000157e550, 30038dfdc80, 3000157e550, 16,
3000005d3b8, 80)
fwstrmodrput+0x2d8(3000157e550, 30038dfdc80, 20, 50, 1860,
8000000000000000)
putnext+0x21c(0, 30038dfdc80, 86c00000, 50, 2a10004b9d8, 12ccb60)
qferead_dvma+0x32c(5400, 50, 300382a3600, 96, 2a10004b9d8, 12ccb60)
qfe_intr+0x150(5508, fffeffff, 300029474c8, 30002942428, 10000, 54c8)
pci_intr_wrapper+0x7c(300002b1208, 793, 1400000, 1400468, f260, 12cfb88)
intr_thread+0x130(b, 0, 0, 2a10007dd40, 0, fffe)
disp_getwork+0x38(1400000, 1400000, 30005f60050, 1438788, 16, 0)
idle+0xc8(0, 0, 1438788, 1438788, 2a10016bd40, 0)
thread_start+4(0, 0, 0, 0, 0, 0)
Kernel Panic on Splat\Linux

Here is the key
<1>Oops: 0000 line
<1>vpnmod_smp.2.4.21.cp.i686 fwmod_smp.2.4.21.cp.i686
vpntmod_smp.2.4.21.cp.i686 e1000.5.2.52 bcm5700 e1000.4.6.11 floppy sg
microcode keybdev mousedev hid input
CPU: 1
<1>EIP: 0060:[<802b482f>] Tainted: PF
<1>EFLAGS: 00010297
<1>EIP is at vsnprintf [kernel] 0x2df (2.4.21-20cpsmp/i686)
<1>eax: 14b95de4 ebx: 0000000a ecx: 14b95de4 edx: fffffffe
<1>esi: c117f1ce edi: 00000000 ebp: ffffffff esp: 83bc193c
<1>ds: 0068 es: 0068 ss: 0068
<1>Process swapper (pid: 0, stackpage=83bc1000)
<1>Stack: c147b714 00000000 80000000 00000000 00000000 c0cedca0 c147b714
00000000

<1> ffffffff ffffffff 14b95de4 00000000 d55c10bf 00000001 802b4a07
c117f1c0
<1> 3ee80e40 c0f5e5d5 83bc19a8 802b4a2f c117f1c0 c0f5e5c6 83bc19a4
c0d1a42b
<1>Call Trace: [<c0cedca0>] fwconn_chain_remove_opaque Here is
[fwmod_smp.2.4.21.cp.i686] 0xa0 (0x83bc1950) where the
<1>[<802b4a07>] vsprintf [kernel] 0x27 (0x83bc1974)
<1>[<c117f1c0>] f_msg.35 [fwmod_smp.2.4.21.cp.i686] 0x0 (0x83bc1978)
stack
<1>[<c0f5e5d5>] .LC100 [fwmod_smp.2.4.21.cp.i686] 0x3b (0x83bc1980) begins
<1>[<802b4a2f>] sprintf [kernel] 0x1f (0x83bc1988)
<1>[<c117f1c0>] f_msg.35 [fwmod_smp.2.4.21.cp.i686] 0x0 (0x83bc198c)
<1>[<c0f5e5c6>] .LC100 [fwmod_smp.2.4.21.cp.i686] 0x2c (0x83bc1990)
<1>[<c0d1a42b>] fw_spii_execute_inspections [fwmod_smp.2.4.21.cp.i686]
0x2bb (0x83bc1998)
<1>[<c117f1c0>] f_msg.35 [fwmod_smp.2.4.21.cp.i686] 0x0 (0x83bc199c)
<1>[<c0f5e5c6>] .LC100 [fwmod_smp.2.4.21.cp.i686] 0x2c (0x83bc19a0)
<1>[<c11cfd88>] fwfuncs [fwmod_smp.2.4.21.cp.i686] 0x0 (0x83bc19a8)
<1>[<c0c19c80>] fw_conn_post_inspect [fwmod_smp.2.4.21.cp.i686] 0x2b0
(0x83bc19f8)
<1>[<c0c1c98a>] fw_cluster_ttl_anti_spoofing [fwmod_smp.2.4.21.cp.i686]
0x3a (0x83bc1a4c)
<1>[<c0c1c2b8>] fw_filter_chain [fwmod_smp.2.4.21.cp.i686] 0xda8
(0x83bc1a74)
<1>[<c10d0c40>] conn.46 [fwmod_smp.2.4.21.cp.i686] 0x0 (0x83bc1a7c)
<1>[<c0d5d16a>] cpas_glue_pkt_h_out [fwmod_smp.2.4.21.cp.i686] 0x4a
(0x83bc1a88)
<1>[<c0c4dd56>] fwchain_do_ [fwmod_smp.2.4.21.cp.i686] 0x266 (0x83bc1aa8)
<1>[<c117b420>] new_entry.16 [fwmod_smp.2.4.21.cp.i686] 0x0 (0x83bc1abc)
<1>[<c0c4e0e3>] fwchain_do_ex [fwmod_smp.2.4.21.cp.i686] 0x63 (0x83bc1ad0)
<1>[<c0c2349e>] fw_filter [fwmod_smp.2.4.21.cp.i686] 0x11e (0x83bc1af0)
<1>[<c0c8d6df>] fwlinux_nfipout [fwmod_smp.2.4.21.cp.i686] 0x24f
(0x83bc1b14)
>[<c0ce83e8>] fwlddist_refresh [fwmod_smp.2.4.21.cp.i686] 0x1d8
(0x83bc1b30)
<1>[<c0c8c970>] fwlinux_filterout_finish [fwmod_smp.2.4.21.cp.i686] 0x0
(0x83bc1b5c)
<1>[<c1090e80>] fwnf_iptops [fwmod_smp.2.4.21.cp.i686] 0x60 (0x83bc1b64)
<1>[<8025e720>] ip_finish_output2 [kernel] 0x0 (0x83bc1b78)
<1>[<8025e720>] ip_finish_output2 [kernel] 0x0 (0x83bc1b80)
<1>[<80248184>] nf_iterate [kernel] 0x54 (0x83bc1b8c)
<1>[<8025e720>] ip_finish_output2 [kernel] 0x0 (0x83bc1ba0)
<1>[<8025e720>] ip_finish_output2 [kernel] 0x0 (0x83bc1bb0)

7KH)LUH:DOO KWWSGOFKHFNSRLQWFRPSDLGIQNBIZBGHEXJKWPO"+DVK.H\
)LUH:DOO.HUQHO'HEXJ2SWLRQV
7KH)LUH:DOONHUQHOPRGXOHPD\EHSXWLQWRGHEXJPRGHZLWKWKHIROORZLQJFRPPDQG
QRNLDBIZ>DGPLQ@IZFWOGHEXJGHEXJRSWLRQ!
7KHIROORZLQJDUHYDOLGGHEXJRSWLRQV
WXUQGHEXJJLQJRIIIZFWOGHEXJ
DOO'212786(
DOOGHEXJIHDWXUHV
7KHRXWSXWLVH[FHVVLYHPDNLQJWKHV\VWHPXQUHVSRQVLYH2IWHQRQO\DFROGUHERRWZLOOUHVWRUHDFFHVVWRWKH
V\VWHP
FRRNLHFRRNLHDEVWUDFWGDWDW\SHRIUHSUHVHQWLQJSDFNHWVUHODWHGPHVVDJHV
FU\SWHQFU\SWLRQUHODWHGLQIRUPDWLRQ
GRPDLQGRPDLQTXHULHV
GULYHUGHYLFHGULYHURSHUDWLRQV
ILOWHUILOWHUORDGLQJDQGXQORDGLQJ
KROGSDFNHWVKHOGDQGUHOHDVHGUHODWHGDPRQJRWKHUWKLQJVWRHQFU\SWLRQ
LILQWHUIDFHELQGLQJ
LQVWDOOGULYHULQVWDOODWLRQ
LRFWOLRFWOFRPPDQGVIURPWKHGDHPRQ
NEXINHUQHOEXIIHUVEXIIHUVDOORFDWHGE\WKHNHUQHOIRUHQFU\SWLRQSXUSRVHV
OGRSHUDWLRQVRQG\QDPLFWDEOHV
ORJORJPHVVDJHVVHQWWRWKHGDHPRQ
PDFKLQHYLUWXDOPDFKLQHRSHUDWLRQWKHYLUWXDOPDFKLQHZKLFKH[HFXWHVWKH,163(&7FRGHFRPSLOHGIURPSIILOHV
PHPRU\PHPRU\XVDJH
PLVFDOORWKHUV
SDFNHWSDFNHWKDQGOLQJ
SURILOHSHUIRUPDQFHPRQLWRULQJ
TVWUHDPVDQGTXHXHVRSHUDWLRQV
V\QDWNRSHUDWLRQVUHODWHGWRV\QDWWDFNSURWHFWLRQ
WFSVHT7&3VHTXHQFHQXPEHUVFKDQJHG
ZLQQWZLQGRZV17VSHFLILFRSHUDWLRQV
[ODWHDGGUHVVWUDQVODWLRQIRUQHZFRQQHFWLRQV
[OWUFDGGUHVVWUDQVODWLRQIRUWHOQHWDQGIWS
5HGLUHFWLQJ2XWSXWWRD)LOH
7KHLQIRUPDWLRQLVVHQWE\GHIDXOWWRWKHFRQVROH,WFDQDOVREHVHQWWRDNHUQHOEXIIHU7KLVLVQHFHVVDU\EHFDXVHWKHRXWSXW
RIWHQLVWRJUHDWWRSURFHVVUHDOWLPH+HUHDUHVRPHH[DPSOHVRIKRZWRUHGLUHFWWKHRXWSXWWRDILOHIRUH[DPLQDWLRQODWHU
QRNLDBIZ>DGPLQ@IZFWOGHEXJEXI>@
7KHGHIDXOWVL]HLV.E\WHV$WWKLVSRLQW\RXKDYHRQO\HQDEOHGWKHUHGLUHFWLRQRIVWGRXWWRDEXIIHUEXWWKHQH[WVWHSLV
UHWULHYHWKHFRQWHQWVRIWKLVEXIIHU7KLVLVGRZQZLWKWKHIROORZLQJFRPPDQG
QRNLDBIZ>DGPLQ@IZFWONGHEXJI
GH 30
7KLVZLOOQRZGXPSWKHEXIIHUWRVWGRXWEXWWKLVLVVLPLODUWREHIRUH7KHIROORZLQJDUHWKHVWHSVWRUHGLUHFWWKHEXIIHUWRD
ILOH
QRNLDBIZ>DGPLQ@IZFWOGHEXJEXI
QRNLDBIZ>DGPLQ@IZFWOGHEXJRSWLRQ!
QRNLDBIZ>DGPLQ@IZFWONGHEXJI!ILOHVSHF
QRNLDBIZ>DGPLQ@WDLOIILOHVSHF
:KHQ\RXKDYHJDWKHUHGHQRXJKLQIRUPDWLRQSUHVV&75/&!WRVWRSWKHRXWSXWWRWKHILOH<RXZLOOKDYHWRLVVXH
CIZFWOGHEXJCLQRUGHUWRDFWXDOO\UHVWRUHWKHNHUQHOWRQRUPDORSHUDWLRQ
'HEXJJLQJ+7736HFXULW\6HUYHU
:HXVHGWKHVHEHORZZKHQZHGHEXJJHG+7736HFXULW\6HUYHUSUREOHPV2QHRIWKHYXOQHUDELOLWLHVLQWKH+7736HFXULW\
6HUYHULVWKDWLWZLOOEORFNDOOQHWZRUNFRQQHFWLRQVLWLVFKHFNLQJLID85/LVQRWUHVROYDEOH7KLVLVVHULRXVLQWKDWD'26RI
'16WR\RXUILUHZDOOFDQFULSSOHLW)RUH[DPSOHLI\RXFUHDWHD85,UHVRXUFHREMHFWWRH[SOLFLWO\EORFN+773WR
ZZZVRPHGRPDLQFRPDQGWKLVGRHVQRWUHVROYHWRDQ,3DGGUHVVWKHQDOO+773WKDWLVVXEMHFWWR&RQWHQW6HFXULW\ZLOOEH
EORFNHG
QRNLDBIZ>DGPLQ@VHWHQY+773B'(%8*
QRNLDBIZ>DGPLQ@VHWHQY):$+773'B'(%8*
QRNLDBIZ>DGPLQ@VHWHQY):B'(%8*B(9(17
QRNLDBIZ>DGPLQ@VHWHQY):7B'(%8*DOO
QRNLDBIZ>DGPLQ@IZNLOOIZGIZGCFDW):',5FRQIPDVWHUVC
7KHODWHUYHUVLRQVRI)LUH:DOOHQDEOH6073B'(%8*DQG0'4B'(%8*LQDQRWKHUZD\7KHVHYDULDEOHVVKRXOGEH
GHILQHGLQWKH):',5FRQIVPWSFRQIILOHDQGWKHQWKHIZGSURFHVVVKRXOGEHNLOOHGXVLQJWKH±865VZLWFKZKHQWKLVLV
GRQHWKHGHEXJJLQJLQIRUPDWLRQZLOOVWDUWLPPHGLDWHO\ZLWKRXWWKHQHHGWRUHVWDUWWKHGDHPRQV
7RUHPRYHWKHVHHQYLURQPHQWDOYDULDEOHVH[HFXWHXQVHWHQYHQYBYDULDEOH7KHRXWSXWLVGLUHFWHGWR):',5ORJ
DKWWSGORJ7KLVSDUWLFXODUSUREOHPSURGXFHGQXPHURXVGXSOLFDWHHQWULHVLQWKHORJILOHWKDWZHUHRIWKLVIRUP
>#QRNLDBIZLSUJQRNLDFRP@FDOOLQJDV\QFUHVROYHIRUZZZXQUHVROYHDEOHFRP
>SRUW&RQQHFWLRQUHIXVHG7KX$XJ@>SLG @
)DLOHGWRFRQQHFWWRVHUYHUIRUVLGH DW>7KX$XJ@
>SLG @ZULWHBIURPBTXHXHVLGH FOQW
EXI
GDWD
UHVROYHGBQDPHZZZXQUHVROYHDEOHFRP
W\SHGQVBUHVROYHBE\QDPH

FKDLQBQDPHUHVROYHUBOLVW
FDOOBIXQFWLRQFDFKHGBUHVROYHUBJHWKRVWE\QDPH
UHWXUQBIXQFWLRQ
VHULDOBQXPEHUBUHVROYHUBOLVW
FXUUHQWBVLGH
7KHVSHFXODWLRQZDVWKDW)LUH:DOOZDVDWWHPSWLQJRYHUDQGRYHUWRUHVROYHZZZXQUHVROYHDEOHFRPWRDQ,3DGGUHVV,W
GH 30
ZDVYHULILHGWKDWWKLVSDUWLFXODUGHVWLQDWLRQZDVQRWUHVROYDEOH2QFHWKHUXOHXVLQJD85,UHVRXUFHREMHFWRIW\SH:LOGFDUG
ZKLFKH[SOLFLWO\VSHFLILHGWKLVVLWHZDVUHPRYHGHYHU\WKLQJZDVUHVWRUHG7KLVEXJZDVYHULILHGWREHLQ63IRU6RODULV
RQ$XJWK7KHLPPHGLDWHVROXWLRQLVWRQRWXVHD85,UHVRXUFHREMHFWRIW\SH:LOGFDUGWRGURSRUUHMHFW+773EXWWR
RQO\$FFHSW+773
'HEXJJLQJ60736HFXULW\6HUYHU
:HXVHWKHIROORZLQJWRGHEXJ60736HFXULW\6HUYHU$WWKLVSRLQWLQWLPHZHGRQRWKDYHDJRRGGHILQLWLRQRIZKDWWKHVH
YDULDEOHVGRZLWKWKHH[FHSWLRQWKDWWKH\DOOLQFUHDVHWKHRXWSXWRIGHEXJLQIRUPDWLRQ7KHYDULDEOHVZLWK0'4SXWWKHVSRRO
GHTXHXHUSURFHVVLQWRGHEXJPRGH7KH6073B'(%8*HQYLURQPHQWDOYDULDEOHLVVKRZQZLWKWKUHHOHYHOV&KRRVHRQH
):7B'(%8*LVDVVRFLDWHGZLWKWKHIZGGDHPRQ236(&B'(%8*B/(9(/
QRNLDBIZ>DGPLQ@VHWHQY0'4B'(%8*
QRNLDBIZ>DGPLQ@VHWHQY):0'4B'(%8*
QRNLDBIZ>DGPLQ@VHWHQY6073B'(%8*>@
QRNLDBIZ>DGPLQ@VHWHQY):'B'(%8*FYS
QRNLDBIZ>DGPLQ@VHWHQY):7B'(%8*FYS
QRNLDBIZ>DGPLQ@VHWHQY236(&B'(%8*B/(9(/>@
QRNLDBIZ>DGPLQ@IZNLOOIZGIZGCFDW):',5FRQIPDVWHUVC
7RUHPRYHWKHVHHQYLURQPHQWDOYDULDEOHVH[HFXWHXQVHWHQYHQYBYDULDEOH
'HEXJJLQJ6HFX5HPRWH(QFDSVXODWLRQSUREOHP
QRNLDBIZ>DGPLQ@IZFWOGHEXJFRRNLH
QRNLDBIZ>DGPLQ@IZFWOGHEXJEXI
QRNLDBIZ>DGPLQ@IZFWONGHEXJIILOHVSHF
QRNLDBIZ>DGPLQ@WDLOIILOHVSHF

:HVKRXOGVHHPHVVDJHVRIWKHIRUPFRRNLHGDWDFRXOGQRW;;;7KHUHZLOOEHPHVVDJHVWKDWVSHFLILFDOO\FRPSODLQDERXW
IUDJPHQWDWLRQ
6HFX5HPRWHPD\EHSODFHGLQWRGHEXJPRGHE\FUHDWLQJWKHILOHIZHQFORJDWWKHURRWRI\RXUV\VWHPGULYH)RUH[DPSOH
WKLVPLJKWEHF?IZHQFORJ
'HEXJJLQJWKHLQSLQJGGDHPRQ
QRNLDBIZ>DGPLQ@VHWHQY):3,1*B'(%8*
7KHRXWSXWRIIZWDEWFKHFNBDOLYHLVDOVRDQDO\]HG
GH 30
Technical Support Files Needed for Troubleshooting
Abstract
Check Point Technical Services requests files or information to help facilitate problem resolution. The following
document is provided to customers and partners may anticipate what information or files will be requested based on
the type of problem they are experiencing.
Document Title: Files Needed for Troubleshooting

Creation Date: 7-Jan-2004
Modified Date: 8-Jan-2004
Document Revision: 2
TABLE OF CONTENTS
ABSTRACT ...................................................................................................................................................................1
OVERVIEW....................................................................................................................................................................3
FIREWALL-1 .................................................................................................................................................................4
General .....................................................................................................................................................................4
CORE Crash .............................................................................................................................................................4
Dr. Watson ................................................................................................................................................................4
INSPECT...................................................................................................................................................................4
Kernel Crashes..........................................................................................................................................................4
LOG...........................................................................................................................................................................4
Network Address Translation ....................................................................................................................................4
Resources: CVP........................................................................................................................................................5
Rule Base Problems..................................................................................................................................................5
Security Server..........................................................................................................................................................5
APPLIANCE PRODUCTS .............................................................................................................................................5
CVP & UFP Problems ...............................................................................................................................................5

Nokia .........................................................................................................................................................................5
OSE...........................................................................................................................................................................5
SecurePlatform..........................................................................................................................................................5
Small Office Products................................................................................................................................................6
OPSEC Application ...................................................................................................................................................6
HIGH AVAILABILITY ....................................................................................................................................................6
ClusterXL ..................................................................................................................................................................6
Rainfinity Rainwall .....................................................................................................................................................6
Stonesoft Stonebeat Full Cluster...............................................................................................................................6
Reporting Module ......................................................................................................................................................6
FloodGate-1 ..............................................................................................................................................................7
ENTERPRISE PRODUCTS ...........................................................................................................................................7
General .....................................................................................................................................................................7
Provider-1..................................................................................................................................................................7
SiteManager-1...........................................................................................................................................................7
User Authority............................................................................................................................................................7
FireWall-1 GX (Wireless)...........................................................................................................................................8
Customer Logging Module ........................................................................................................................................8
Management Logging Module ...................................................................................................................................8
LDAP Account Management .....................................................................................................................................8
VSX ...........................................................................................................................................................................8
ENCRYPTION PRODUCTS...........................................................................................................................................8
VPN-1 Pro .................................................................................................................................................................8

VPN-1 Net .................................................................................................................................................................9
VPN-1 Edge ..............................................................................................................................................................9
SecuRemote..............................................................................................................................................................9
SecureClient..............................................................................................................................................................9
VPN-1 Mac Client....................................................................................................................................................10
VPN-1 Accelerator Cards ........................................................................................................................................10
SecureXL TurboCard ..............................................................................................................................................10
PKI ..........................................................................................................................................................................10
DOCUMENTING TROUBLESHOOTING PRIOR TO CONTACTING SUPPORT .......................................................11
Files Needed for Troubleshooting Page 2 of 11

Revision: 2
Overview
This document will provide a list of information or files that may be requested by Check Point Technical
Services when a customer or partner is experiencing a problem with any of the following technologies:
‚" FireWall-1
‚" Appliance Products
‚" High Availability Products
‚" Enterprise Products
‚" Encryption Products
Additionally, this document will detail how a customer or partner can provide information about
troubleshooting steps he or she may have already done prior to contacting support.

Revision: 2
FireWall-1
General
‚" Complete contact information, (name, title, company name, e-mail address, phone number, pager number,
fax number, onsite phone number, time zone) for all parties involved in the issue.
‚" Execute the $FWDIR/bin/fwinfo, cpinfo, or ipsoinfo command on all FireWall-1 modules and the FireWall-
1 management station in question, divert the output to a file, and attach the file to a web request.
‚" Describe the hardware platform(s) involved in this issue, including the amount of memory, disk space, and
NIC card types (manufacturer and model).
‚" Describe the operating system(s) involved in this issue, including the version number and patch level
information. (Include which service pack and hotfixes for NT, which patches for Solaris, etc.).
‚" Provide a detailed description of the problem or issue, including any symptoms noted, any patterns seen
(time of day or only certain users affected, etc…) and any specific error messages received.
‚" Log file contains relevant log errors
‚" Updated SVN Mapping of all the network related to the problem including Hardware/Software detailed
descriptions, Network Map, Connections types, bandwidth, and IP addresses of all segment routers and
transitional gateways.
‚" General information about the network, including: approximate number of users, approximate number of
simultaneous sessions per user, types of applications in use, network traffic passing through the software at
the time of error, CPU utilization, memory allocation and utilization.
‚" An electronic topology diagram is preferred – Visio® or PowerPoint® are good applications to use for this. If
this is not feasible, a fax of hand drawn diagrams is an acceptable alternative, provided the IP addresses or
Host ID information is legible upon receipt.
CORE Crash
‚" Core File
Dr. Watson
‚" Dr. Watson file (drwtsn32.log)
‚" User.dmp file (system.dmp in case of a blue screen).
INSPECT
‚" If a specific SERVICE was mentioned, specify the following:
o How does the service work
o On which protocol does the service work
o On which ports does the service work
‚" fwmonitor + a list of the relevant IPs (client, server, FireWall).
Kernel Crashes
‚" vmcore.x file
‚" unix.x file
LOG
‚" If the problem is related to the Log Viewer, issue the command ‘fw logexport’ in order to see if all
the columns are full.
‚" If the log records are not written to the log file (‘fw log’ and ‘fw logexport’ show no new records), you may
want to run “fw d –d –D”, which includes special debugging option for FW1_LOG connections for VPN-
1/FireWall-1 v4.1.
o fw debug fwd on --> log/fwd.elg
o fw debug fwm on --> log/fwm.elg
Network Address Translation

‚" fwmonitor + a list of the relevant IPs (client, server ,FireWall)
Revision: 2
‚" Issue the command
o fw ctl debug -buf
o fw ctl debug xlate
o fw ctl kdebug -f > /tmp/kdebug.out
and send the file (In case of FTP or TELNET, you can add the option ‘xltrc’ after the option ‘xlate’)..After the
problem occurs, stop this command with ^C, and run ‘fw ctl debug 0’.
Resources: CVP
‚" Issue the command ‘snoop’ on port 18181
‚" fwopsec.conf file
‚" cvp.conf file on the CVP side
‚" Set the environment variable OPSEC_DEBUG_LEVEL to 3, and restart fwd. Send the output received in
fwd.log.
Rule Base Problems

Security Server
‚" Run the Authentication daemon in Debug and send the log/ahttpd.elg file.
‚" If the problem is related to SMTP, send the spool directory and run the mail dequeuer and the
asmtpd in debug mode.
Appliance Products
CVP & UFP Problems
‚" cpinfo from FireWall-1 Enforcement module
‚" cpinfo from SmartCenter Management module
‚" CVP or UFP product name and version
‚" URL of web site if the problem is with accessing a certain web site
‚" ahttpd, aftp etc. debug (in case it's http related issue)
‚" fw monitor (including the IP addresses of all parties)
‚" Web/FTP site trying to be accessed
‚" fw.log file (when there are error messages in the log viewer.) or an export of the relevant log
records
‚" Important: Make sure you verify whether the problem occurs with/without UFP/CVP
Nokia
‚" ipsoinfo from FireWall-1 Enforcement module
‚" ipsoinfo from SmartCenter Management module
OSE
‚" Router type and OS version
‚" For Cisco and Nortel (Bay), obtain a copy of the routers configuration (*cfg file)
SecurePlatform
‚" For user mode crash - send the user dump
o Use the 'ulimit -c unlimited' command to configure the machine to generate cores.
‚" For kernel mode crashes:
Revision: 2
o Send the crash dump file located in: /var/log/dump/x (where x is the crash number)
o Send the /var/log/dump/analysis file
‚" Did customer add patches? Which ones?
‚" Hardware
‚" NIC Drivers (if the problem related to NIC)
Small Office Products

‚" Small Office product name & model number
‚" Hot Fix number (if any used)
‚" History of RPM installations
OPSEC Application
‚" Vendor and version of OPSEC application
‚" cpinfo from management and module
‚" Log files from the OPSEC vendor application (when available)
‚" OPSEC debug on the Application side (when available)
o Usually to run it simultaneously with FireWall-1 OPSEC debug (on the FireWall-1 module
side)
High Availability
ClusterXL
‚" cpinfos from the SmartCenter Server and Enforcement points
‚" fw ctl debug –buf 4096
‚" fw ctl debug –m cluster all
‚" fw ctl kdebug –f > <file name>
Rainfinity Rainwall
‚" cpinfo
‚" Rainfinity version
‚" *.cfg files from Rainwall
‚" fw ctl debug misc
Stonesoft Stonebeat Full Cluster

‚" cpinfo
‚" StoneBeat version
‚" sbinfo
‚" $sbfchome/etc directory from StoneBeat
‚" fw ctl debug misc - only if they use sync
Reporting Module
‚" cpinfo (from SmartCenter only)
Revision: 2
‚" reporting server directory (Program Files/Checkpoint/Reporting Module or
‚" /opt/CPrt-50 directory disregarding the database directory)
‚" rtserver debug
‚" log consolidator debug
‚" The fw log files $FWDIR/log directory
FloodGate-1
‚" cpinfo
‚" fw ctl debug -m FG-1
Enterprise Products
General
‚" Latest cpinfo file
Provider-1
‚" cpinfos from MDS environment and CMA environment
‚" SIC problems
o cpd debug on MDS
o cpd debug on individual CMA
‚" Copy of $MDSDIR/conf/mdsdb directory (the latest cpinfo includes it)
‚" fwd debug for logging/status/connectivity issues
‚" fwm debug for gui/management issues
‚" mds_backup
SiteManager-1
‚" cpinfos from MDS environment and CMA environment
‚" SIC problems
o cpd debug on MDS
o cpd debug on individual CMA
‚" Copy of $MDSDIR/con/mdsdb directory
‚" fwd debug for logging issues
‚" fwm debug for GUI/management issues
‚" mds_backup
User Authority
‚" cpinfo from management and gateway
‚" netsod debug on gateway
‚" SIC problems
o cpd debug on domain controller
‚" Information from Domain Controller for authentication problems:
‚" cpinfo, netsod debug, ipconfig /all output
‚" Netcat between Domain controller and Secure Agent.
‚" Netcat between Module and Domain Controller

Revision: 2
FireWall-1 GX (Wireless)
‚" cpinfo from management/gateway
‚" Good topology description
‚" fw.log
Customer Logging Module

‚" GUI problems - fwm debug
‚" Logging problems - fwd debug
‚" SIC problems - cpd debug
‚" cpinfo
‚" Check to determine if there are crashes
Management Logging Module

‚" cpinfo on MDS for MDS and problematic CMA environment
‚" cpinfo from MLM $MDSDIR and corresponding CLM environments
‚" GUI problems
o fwm debug in proper CLM $FWDIR
‚" Logging problems
o fwd in proper CLM $FWDIR
‚" mds_backup
LDAP Account Management

‚" cpinfo from SmartCenter Server and Enforcement module
‚" fw monitor of traffic between Enforcement module and LDAP server
‚" output of ldapsearch command
‚" fwd debug output
‚" Product name and version of the LDAP server and any relevant logs or errors messages from it.
VSX
‚" mds_backup from Provider-1 VSX MDS
‚" cpinfo from the problematic CMA environment (mdsenv <cma name>)
‚" output of fw vsx stat –v command on the VSX Gateway
‚" cpd.elg (cpd_admin debug on) from the VSX MDS and Gateway for virtual system creation, policy
installation and SIC issues
‚" fw monitor –vs <vsid> from problematic Virtual System
‚" cpinfo –c <vsid> -o <file> from the VSX Gateway
‚" fw ctl debug with necessary flags
Encryption Products
VPN-1 Pro
‚" Monitor from VPN-1 Enforcement modules involved in VPN
‚" vpnd.elg file from VPN-1 Enforcement modules involved in VPN (vpn debug on)
‚" IKE.elg file from VPN-1 Enforcement modules involved in VPN (vpn debug ikeon)
‚" Any error messages seen in log viewer
‚" cpinfo from VPN-1 Enforcement modules involved in VPN
Revision: 2
‚" cpinfo from SmartCenter Management module(s) of the above VPN-1 Enforcement modules
‚" Network description
‚" Core files if any
VPN-1 Net
‚" Monitor from VPN-1 Enforcement modules involved in VPN
‚" cpinfo from SmartCenter Management module(s) of the above VPN-1 Enforcement modules
‚" Core files if any
VPN-1 Edge
‚" http://my.firewall/pub/test.html
‚" diagnostics output from http://my.firewall, setup> firmware> diagnostics
‚" exported configuration (.cfg) from http://my.firewall, setup> tools> export
‚" cpinfo from central site VPN-1 Enforcement module(s) and SmartCenter Server involved in VPN
‚" vpnd.elg and ike.elg from central site VPN-1 Enforcement modules involved in VPN (vpn debug
on, vpn debug ikeon)
SecuRemote
‚" Monitor from VPN-1 Enforcement modules involved in client to FireWall VPN
‚" Monitor (or anlz) output from client involved in client to FireWall VPN
‚" IKE.elg file from client involved in client to FireWall VPN
‚" cpinfo from SmartCenter Management module(s) of the above FireWalls
‚" srinfo from client
‚" *.log files form log directory
SecureClient
‚" Monitor (or anlz) output from client involved in client to FireWall VPN
o The command "srfw monitor.." - starting from NG FP2
‚" IKE.elg file from client involved in client to FireWall VPN
‚" cpinfo from SmartCenter Management Module(s) of the above FireWalls
‚" srinfo from client
o If it's a problem getting the policy, or logging onto the Policy Server, we'll need the
dtpsd.elg file (dtps debug on)
‚" *.log files from log directory

Revision: 2
VPN-1 Mac Client
‚" *.alf files from VPN-1 Client folder on the Macintosh in question
‚" cpinfo from SmartCenter Management Module(s) of the above FireWalls
VPN-1 Accelerator Cards

‚" Output of 'vpn accel stat -l'
‚" Collect console error messages
o Windows - Error messages in event viewer (copy of event logs)
o Solaris - /var/adm/messages
o Linux - /var/log/messages
‚" lunadiag (test #9)
‚" bcmdiag used via the GUI in Win NT/Win 2000 or via commands: bcmdiag -(vsx) in Linux and
Solaris
SecureXL TurboCard
‚" Output of ‘fwaccel stat’
‚" Output of ‘fwaccel conns’
‚" Output of ‘vpn accel stat ‘ for encryption issues
‚" fwaccel dbg <flag>
‚" fw ctl debug –f > <file>
PKI
‚" output of vpn crlview –d –obj <fw object name> -cert <cert nickname>
‚" vpnd.elg (with vpn debug on)
‚" ike.elg with (vpn debug ikeon)
‚" cpinfos
‚" Certificate authority product name and version and output of any relevant logs or error messages
from the server.

Revision: 2
Documenting Troubleshooting Prior to Contacting Support
Check Point encourages customers and partners to provide any troubleshooting information they may
have done prior to contacting Check Point. To help our technical advisors easily determine what a
customer or partner may have already reviewed, please be ready to provide or document the as much of
the following information as possible:
‚" Additional/Alternate Customer's Contact name, email address & phone #

‚" Problem description including: current OS & FW (include hotfix) version, what triggered the
problem (include specific error messages)
‚" Business Impact
‚" Network topology (Include other CP products/builds and other involved machines)
‚" If other servers are involved, state product name, version etc
‚" What was checked /tested (detail tests and results)
‚" What databases were used for reference/troubleshooting (SecureKnowledge/Manuals/etc.) and
what were the results
‚" Suggested next steps
‚" Attached files
If you believe you have discovered a bug, please provide the following information:
Bug information:
‚" Brief problem summary
‚" Test results summary
‚" Test bed configuration (test rack setup)
‚" Test methodology (procedure used to replicate)
‚" Any relevant crash or debug files

Revision: 2
19/07/2017 Check Point Firewall: Troubleshooting Checkpoint VPNs with IKEVIEW
Troubleshooting Checkpoint VPNs with IKEVIEW

[12:43 AM | 96 comments ]
Using IKEVIEW for VPN debugging
IKEVIEW is a Checkpoint Partner tool available for VPN troubleshooting purposes. It is a Windows executable that can be
downloaded from Checkpoint.com. Ikeview was originally only available to Checkpoint's CSP partners however they will
gladly supply you a copy of thie file if you have a licensed Checkpoint product. This file parses the IKE.elg file located on the
firewall.
http://pingtool.org/downloads/IKEView.exe
To use IKEVIEW for VPN troubleshooting do the following:
1. From the firewall type the following:
vpn debug ikeon
This will create the IKE.elg file located in $FWDIR/log
2. Attempt to establish the VPN tunnel. All phases of the connection will be logged to the IKE.elg file.
3. SCP the file to your local desktop.

WINSCP works great
4. Launch IKEVIEW and select File>Open. Browse to the IKE.elg file.
Understanding the IKE.elg output
All Phase I packets will either be labeled Main Mode or Aggressive Mode.
Phase II packets will be labeled QM or Quick Mode.
An arrow pointing to the left (<) indicates IPSEC packets that the Checkpoint firewall (local) receives from the remote Peer.
An arrow pointing to the right (>) represent IPSEC packets that the Checkpoint firewall is sending to the remote peer.
Ikeview Phase I Main Mode exchange:
If your encryption fails in Main Mode Packet 1, then you need to check your VPN proposal (encryption/hash/lifetime).
Packet 2 ( MM Packet 2 in the trace ) is from the responder to agree on one encryption and hash algorithm
Packets 3 and 4 aren’t usually used when troubleshooting. They perform key exchanges and include a large number called
a NONCE. The NONCE is a set of never before used random numbers sent to the other part, signed and returned to prove
the parties identity.
Packets 5 and 6 perform the authentication between the peers. The peers IP address shows in the ID field under MM
packet 5. Packet 6 shows that the peer has agreed to the proposal and has authorised the host initiating the key
exchange.
If your encryption fails in Main Mode Packet 5, then you need to check the authentication - Certificates or pre-shared
secrets
Phase I Main Mode example:
In the example below, we see that Phase I is failing after the first packet (Main mode Phase I takes 6 packets to complete).
After the first packet (the initial proposal packet), we see that the remote peer responds with No Proposal Chosen. In this
example, the remote peer rejected the local proposal of AES/SHA1 with a lifetime of 86400 seconds and the provided
Preshared key.
http://check-point-firewall.blogspot.com.br/2012/03/roubleshooting-checkpoint-vpns-with.html 1/3
Phase II Quick Mode exchange:
Next is Phase II - the IPSec Security Associations (SAs) are negotiated, the shared secret key material used for the SA is
determined and there is an additional DH exchange. Phase II failures are generally due to a misconfigured VPN domain.
Phase II occurs in 3 stages:
1. Peers exchange key material and agree encryption and integrity methods for IPSec.
2. The DH key is combined with the key material to produce the symmetrical IPSec key.
3. Symmetric IPSec keys are generated.
In IkeView under the IP address of the peer, expand Quick Mode packet 1:
> "P2 Quick Mode ==>" for outgoing or "P2 Quick Mode <==" for incoming > QM Packet 1
> Security Association
> prop1 PROTO_IPSEC_ESP
> tran1 ESP_AES (for an AES encrypted tunnel)
You should be able to see the SA life Type, Duration, Authentication Alg, Encapsulation Mode and Key length.
If your encryption fails here, it is one of the above Phase II settings that needs to be looked at.
There are two ID feilds in a QM packet. Under
> QM Packet 1
> ID
You should be able to see the initiators VPN Domain configuration including the type (ID_IPV4_ADDR_SUBNET) and data (ID
Data field).
Under the second ID field you should be able to see the peers VPN Domain configuration.
Packet 2 from the responder agrees to its own subnet or host ID, encryption and hash algorithm.
Packet 3 completes the IKE negotiation.
Phase II Quick Mode example:
Below is a screenshot of a failed VPN connection for Phase II. From this example, we can see that Phase I(Main Mode)
completed successfully. Phase II (Quick Mode) shows a Failed status.
As indicated below, there is an Outgoing proposal (local peer) for AES/SHA1 with a lifetime of 3600 seconds. After the failed
Phase II packet, there is an Info packet from the remote peer indicating “Invalid ID Information”. This is an indication that
the remote peer rejected our proposal. If the tunnel were being initiated on the Remote End, we would also see the
remote peer’s proposal and can compare that to the local proposal.
Common errors indicated in Ikeview
No Proposal Chosen:
A common error that can be easily identified in IKEVIEW is “No Proposal Chosen”.
In the Quick Mode section that is followed by the info line displaying the “No Proposal Chosen” message should display the
network mask used for the VPN handshake. Compare the mask used in the local encryption domain with the mask sent by
the remote peer. This is a common error when establishing tunnels with non-Checkpoint firewalls. Checkpoint, by default,
supernets networks contained in the encryption domain. The method for resolving this issue on the Checkpoint firewall
differs depending on if the firewall is R55, R61 simple mode, or R61 classic mode. In R55 there is an option in the VPN
section of the Interoperable firewall object that tells the Firewall for “One tunnel per pair of hosts, or one tunnel per pair of
subnets”. In R61 Simple mode, there is an option in the VPN Community that says “exchange key per host”. In R61 Classic
mode you will need to do the following during non-business hours:
CP Stop
Modify the $FWDIR/lib/user.def.
Change the parameter "IKE_largest_possible_subnet" from true to "false".
CP start.
Aggressive Mode failure:
Aggressive mode uses 3 packets instead of 6 during the Phase I negotiations. Therefore if 1 side of the tunnel is configured
for Aggressive Mode and the other side is configured for Main Mode, the 2 peers will not agree with the contents of the first
packet during the exchange. If the local peer is mistakenly configured to use Aggressive Mode (which is a less secure
method), the outgoing packet will be labeled Aggressive Mode.
Invalid ID-Information:
This is an indication that the remote peer rejected either the Phase I or Phase II proposal from the local peer.
PROTO_IPCOMP in the QM packet
This is an indication that IP Compression is enabled for this tunnel.
How To Troubleshoot SIC-
related Issues
11 January 2011
without notice.
52.227-19.
TRADEMARKS:
Latest Software
Revision History
Date Description
1/9/2011 First release of this document
Feedback
(mailto:cp_techpub_feedback@checkpoint.com?subject=Feedback on How To Troubleshoot SIC-related
Issues ).
Contents

How To Troubleshoot SIC-related Issues .............................................................5
Objective ............................................................................................................. 5
Supported OS...................................................................................................... 5
Before You Start .....................................................................................................6
Related Documentation and Assumed Knowledge .............................................. 6
Impact on the Environment and Warnings ........................................................... 7
Basic Information on SIC .......................................................................................8
Management and Gateway Servers Synchronization .......................................... 8
Troubleshooting Procedures .................................................................................9
Basic Troubleshooting Steps ............................................................................... 9
Checking Connectivity ........................................................................................10
Checking CPD Memory Consumption ................................................................10
High CPD Memory Consumption ...................................................................10
Collecting the Debug ..........................................................................................11
Option 1 .........................................................................................................11
Option 2 .........................................................................................................12
Completing the Procedure ...................................................................................12
Verifying ................................................................................................................12
Objective
How To Troubleshoot SIC-related

Issues
Objective
This document explains the steps for troubleshooting SIC failure scenarios with Check Point Security
Gateway servers, both when initiating the SIC, and when testing its status at a specific time.
Supported Versions
· NGX R65 and oldest versions
· NGX R70
· NGX R71
Supported OS
· SecurePlatform
· Relevant for every appliance and open server
· For Open servers, refer to the Hardware Compatibility List in Check Point public site at:
· http://www.checkpoint.com/services/techsupport/hcl/all.html
(http://www.checkpoint.com/services/techsupport/hcl/all.html -
http://www.checkpoint.com/services/techsupport/hcl/all.html)
How To Troubleshoot SIC-related Issues Page 5

Related Documentation and Assumed Knowledge
Before You Start

Related Documentation and Assumed
Knowledge
There are several generic solution articles which can guide you when troubleshooting problems related to
SIC issues.
Initially, go over:
· sk30579 - Troubleshooting SIC (http://supportcontent.checkpoint.com/solutions?id=sk30579)
· sk41513 - How to debug SIC problems http://supportcontent.checkpoint.com/solutions?id=sk41513.
If these do not solve your issue, go over the following flowchart:
Links to the SKs in the above diagram:

· A failure with initilizing SIC:
· sk12688 (http://supportcontent.checkpoint.com/solutions?id=sk12688)
· Getting the error "SIC General Failure:
· Error No. 300:
Before You Start Page 6

Impact on the Environment and Warnings
· Error No. 147:

· Others:

SIC relies on a process called CPD, meaning that while SIC operations are being performed (initiating SIC,
testing SIC status, pulling a certificate from CA, etc.), CPD-related operations will also be executed.
The CPD process is responsible, among other things, for:
· Licensing
· Policy installation (Policy fetch)
· Secure Internal Communication (SIC)
· Status Report (AMON server for the SmartCenter Server)
· Implements a messaging mechanism for other SmartCenter Server daemons
In rare situations, CPD CPU usage can reach a high value during the debug procedure. If this happens, all
CPD-related operations can be affected. This means they will be slower and can have performance issues
for their specific purposes. Other than that, if the system is not extremely loaded, you should not experience
any major impact on it.
Before You Start Page 7

Management and Gateway Servers Synchronization
Basic Information on SIC

Secure Internal Communications (SIC ) is a certificate-based channel for communications between
Modules. Check Point components communicate with each other using SIC.
The interaction between the Security Management server, the Firewall Gateway and other partner-OPSEC
Applications must take place to ensure that the gateways receive all the necessary information from the
Security Management server.
However, whereas information must be allowed to pass freely, it also has to pass securely. This means:
· The communication must be encrypted so that an impostor cannot send, receive or intercept
communication meant for someone else.
· The communication must be authenticated, so that there can be no doubt as to the identity of the
communicating peers.
· The transmitted communication should have data integrity (the communication has not been altered or
distorted in any form).
· The SIC setup process allowing the intercommunication to take place must be user-friendly.
SIC relies on a process called CPD, which is responsible for performing all inter-module communications.
SIC is based on SSL with digital certificates. When the Management Server is installed, a Certificate
Authority (CA) is created. This Certificate Authority issues certificates for all components that need to
communicate to each other. For example, a remote FireWall-1 Module will need to have a certificate from
the Management Server before a policy can be downloaded to this module, or before a license can be
attached to the Module using SecureUpdate.
The purpose of the Communication Initialization process is to establish a trust between Security
Management server and the Check Point gateways. This trust enables these components to communicate
freely and securely. Trust can only be established when the gateways and the Security Management server
have been issued SIC certificates. After successful Initialization, the gateway can communicate with any
Check Point node that possesses a SIC certificate, signed by the same ICA.
Management and Gateway Servers

Synchronization
In order for the SIC between the Management and the Gateway servers to succeed, their clocks must be
properly and accurately synchronized.
When the SIC certificate has been securely delivered to the gateway, the Trust state is: Trust Established.
The SIC status conveys whether or not the Security Management server is able to communicate securely
with the gateway after it has received the certificate issued by the ICA. The most typical status is
Communicating, and any other status indicates there is a problem with the SIC communication.
Communication takes place over the Check Point communication layer. This channel can therefore be
encrypted in various ways. This layer can be called the SIC layer.
SIC layer provides a secure internal communication method between Check Point software entities.
· Port 18209 is used for communication between the VPN-1/FireWall-1 Module and the Certificate
Authority (status, issue, revoke).
· Port 18210 is used to pull certificates from the CA.
· Port 18211 is the port used by the cpd daemon on the Module to receive the certificate (when clicking
Initialize in the Policy Editor).
Basic Information on SIC Page 8

Basic Troubleshooting Steps
Troubleshooting Procedures
In this section:
Basic Troubleshooting Steps 9

Checking Connectivity 9
Checking CPD Memory Consumption 10
Collecting the Debug 11
Basic Troubleshooting Steps

· Ensure connectivity between the gateway and Security Management server.
· Verify that server and gateway use the same SIC activation key.
· Check the date and time of the operating systems and make sure the time is accurate. If the Security
Management server and remote gateway reside in two different time zones, the remote gateway may
need to wait for the certificate to become valid.
· If the Security Management server is behind another gateway, make sure there are rules that allow
connections between the Security Management server and the remote gateway.
· Ensure the Security Management server's IP address and name, are in the /etc/hosts file on the
gateway.
· If the IP address of the Security Management server undergoes static NAT by its local Security
Gateway, add the public IP address of the Security Management server to the /etc/hosts file on the
remote Security Gateway, to resolve to its hostname.
· Restart the CPD deamon with the following commands:
# cpwd_admin stop -name CPD -path "$CPDIR/bin/cpd_admin" -command "cpd_admin

stop"
# cpwd_admin start -name CPD -path "$CPDIR/bin/cpd" -command "cpd"
· Based on sk33764, using the command line of the gateway, type: fw unloadlocal. This removes
the security policy from the Security Gateway server, hence all traffic is allowed through it.
Try again to establish SIC.
Troubleshooting Procedures Page 9

Checking Connectivity
Checking Connectivity
Ensure that the SIC ports are open. As previously mentioned, the SIC ports are:
· Port 18209 is used for communication between the VPN-1/FireWall-1 Module and the Certificate
Authority (status, issue, revoke).
· Port 18210 is used to pull certificates from the CA.
· Port 18211 is the port used by the cpd daemon on the Module to receive the certificate (when clicking
Initialize in the Policy Editor).
To determine if SIC is listening to its network ports on your Check Point device (can be Security Gateway
server or Security Management Server), use the following command:
· On Windows platforms:
· Open CMD and execute: > netstat -na | findstr 18211
· On Linux platforms:
· # netstat -na | grep 18211
· The output should be:
· TCP 0.0.0.0:18211 0.0.0.0:0 LISTENING
A NAT device between the SmartCenter Server and Security Gateway will not have any effect on the ability
of a Check Point enabled entity to communicate using SIC, since the protocol is based on Certificates and
SIC names (and not IPs).
To verify the Gateway is listening for the SmartCenter Server for getting certificates, the CPD debug output
should be as follows:
[CPD ID]@cpmodule[Date] Get_SIC_KeyHolder: SIC certificate read successfully
[CPD ID]@cpmodule[Date] SIC initialization started
[CPD ID]@cpmodule[Date] get_my_sicname_from_registry: Read the machine's sic
name: CN=member_1,O=cpmodule..6vxoys
[CPD ID]@cpmodule[Date] Initialized sic infrastructure
[CPD ID]@cpmodule[Date] SIC certificate read successfully
[CPD ID]@cpmodule[Date] Initialized SIC authentication methods
Checking CPD Memory Consumption

High CPD Memory Consumption
A memory leak is a particular type of unintentional memory consumption by a computer program (or
daemon in Linux) where the program fails to release memory when it is no longer needed. In the case of a
memory leak, memory usage steadily increases until no memory is left to be allocated. At this point, the
process will crash and probably leave behind a core file that comptidrd the recorded state of the working
memory of the daemon at the crashed time.
To ascertain that you are dealing with such problem, monitor the ‘top’ command output in the involved
servers while replicating the problem (In case of a long term leak, Check Point support can also provide a
special script that can be executed on the system and will collect this data at a constant interval).
While monitoring the ‘top’ command output, the necessary columns are:
· RES (or RSS) – For high memory consumption of specific process (for example – fwm).
· %CPU – For high CPU consumption.
It is also possible to sort this output, as follows - pressing:
· M – sorts the output based on the memory usage (RSS column).
· P – sorts the output based on the CPU usage (%CPU column).

Collecting the Debug
Usually, when the server suffers from high memory consumption, the affected process will eventually crash,
since (due to Linux limitation) it can only reach a memory consumption of ~2GB.
To create the core file, enable the option of a core dump creation, as follows:
On the server where the process crashes:
# um_core enable
# ulimit –c unlimited
# reboot
which provides the core file that will be generated after the next crash.
· The core file name should be similar to: <proc_name>.<core_serial_number>.core
· File should be created under /var/log/dump/usermode.
The process can crash immediately after performing the operation which is related for that process (means it
it is not necessarily a leak, just large enough to cause a crash at a specific point). In such cases, the core
dump file size can take few hundred MB, or after some time on which the memory usage for this process
reaches the highest limit it is capable of, where the core dump file can take more than 2 GB.
Many high memory consumptions issues are solved on the HFA releases, therefore, if you encounter such
an issue, try to install the latest HFA. If it is a known issue, the HFA will probablyovercome it.
If the issue was not solved during the latest HFA, collect the core file (if it was created), together with the
TOP command output that shows the high usage and send this information to Check Point support.
Since SIC operations are performed by the CPD daemon, the monitored process should be the CPD on
both the Security Management server and the Security Gateway server.
Refer to sk35496 (http://supportcontent.checkpoint.com/solutions?id=sk35496 ) for instructions how to
detect high memory consumption (memory leak) on your Security Gateway server.

If none of the above steps solved your SIC issue, you will have to debug the scenario.
Because SIC relies on the CPD process, this is the relevant process to be debugged.
To debug SIC-related scenarios:
Option 1
1. Clean the old log file(s), by issuing:
· # rm $CPDIR/log/cpd.elg.*
· # echo ' ' > $CPDIR/log/cpd.elg
2. Start the debugging:
· # echo ‘===debug_start===’ >> $CPDIR/log/cpd.elg
· # cpd_admin debug on TDERROR_ALL_ALL=5
· # cpd_admin debug on OPSEC_DEBUG_LEVEL=9
3. Replicate the problem
4. Stop the debugging:
· # echo ‘===debug_stop===’ >> $CPDIR/log/cpd.elg
· # cpd_admin debug off TDERROR_ALL_ALL=0
· # cpd_admin debug off OPSEC_DEBUG_LEVEL=0
5. Debug output files, located at:
· $CPDIR/log/cpd.elg*

Option 2
1. Stop the CPD process:
· # cpwd_admin stop -name CPD -path "$CPDIR/bin/cpd_admin" -command
"cpd_admin stop"
2. Enable the debug flags:
· # export TDERROR_ALL_ALL=5
· # export OPSEC_DEBUG_LEVEL=9
3. Start CPD on debug level:
· # cpd –d > cpd_debug.txt 2>&1
4. Replicate the problem.
5. Issue CTRL+C to stop the ‘cpd -d‘ debug.
6. Disable the debug flags:
· # unset TDERROR_ALL_ALL
· # unset OPSEC_DEBUG_LEVEL
The debug output file is cpd_debug.txt which is located on your current directory.These should provide
an indication about the issue that causes the SIC failure. When finding a suspicious log entry within these
files (look for error, fail, etc.), it is necessary to look for it on Secure Knowledge database (Check Point
public site). If nothing similar is found, open a new Service Request with Check Point support and provide
the information you collected.
For further debug information, please refer to sk41513
(http://supportcontent.checkpoint.com/solutions?id=sk41513 ) - How to debug SIC problems.
Completing the Procedure

· Make sure you have gone through all the steps in the Troubleshooting Procedures.
Verifying
To verify that the issue you encountered has been solved:
1. Check that SIC is established with the Security gateway. Go to the gateway object in SmartDashboard.
2. In the General Properties tab, under the Secure Internal Communication section, click Communicate.
3. In the opened window, click Test SIC Status.
The most typical status is Communicating. Any other status indicates that the SIC communication is
problematic. If the SIC status is Not Communicating, the Security Management server is able to
contact the gateway, but SIC communication cannot be established.
If after going over the steps in this guide the SIC status is anything other than Communicating, contact
Check Point support and open a new Service Request with all the relevant information collected in this
procedure.
Completing the Procedure Page 12

How to Troubleshoot
Logging Issues
29 August 2011
without notice.
52.227-19.
TRADEMARKS:
Latest Software
Revision History
Date Description
Feedback
(mailto:cp_techpub_feedback@checkpoint.com?subject=Feedback on How to Troubleshoot Logging Issues
).
Contents

How To Troubleshoot Logging Issues ..................................................................5
Objective ............................................................................................................. 5
Supported Operating Systems ............................................................................. 5
Impact on the Environment and Warnings............................................................5
Troubleshooting Procedures .................................................................................5
Preliminary Questions ......................................................................................... 5
Incorrectly Configured Standalone Deployments ................................................. 6
The Security Management server is not in the Listening State ............................ 6
Network Connectivity ........................................................................................... 6
Installing a Policy ................................................................................................. 7
Making Sure that Logs are Sent .......................................................................... 7
Verifying the Masters File .................................................................................... 7
Using tcpdump to Verify Network Connections .................................................... 7
Doing a Log Switch.............................................................................................. 8
Removing Possible Corrupted Files ..................................................................... 8
Using Debug........................................................................................................ 8
Verification ..............................................................................................................8
Index ........................................................................................................................9
Objective
How To Troubleshoot Logging Issues

Objective
Sometimes the Security Management server stops receiving logs from the Security Gateways that it
manages. In this situation, the Security Gateways save their log files locally, using up disk space according
to the quantity of log entries generated.
This document contains practical troubleshooting procedures that can be used to resolve many different
types of logging issues.
Supported Operating Systems

All supported operating systems.
All supported appliances.
Supported Versions
All supported versions, including R70 and higher.
Impact on the Environment and

Warnings
The potential impact depends on the troubleshooting steps. See the notes applicable to each step.
Troubleshooting Procedures
Preliminary Questions
These are some questions that you should ask before troubleshooting logging issues:
· Is this a new installation?
· Were the logs operating correctly before the issue started?
· What recent changes could possibly cause this issue?
· Does the Security Management server receive logs from many Security Gateways or from one Security
Gateway?
· If the Security Management server receives logs from many Security Gateways, is the issue with all or
only one Security Gateway?
The answers to these questions can help determine which troubleshooting steps are appropriate.
How To Troubleshoot Logging Issues Page 5

Incorrectly Configured Standalone Deployments
Note - You can resolve many logging issues simply by rebooting the Security
Gateway or the Security Management server. You should always try rebooting
before doing more complex troubleshooting procedures. Of course, if logging issues
occur frequently, you should try these troubleshooting procedures.
Incorrectly Configured Standalone

Deployments
A standalone deployment is where a Security Management server and Security Gateway are installed on
the same computer. In a distributed deployment, the Security Management server is installed on one
computer and the Security Gateways are installed on different computers.
Make sure that your Security Management server is not incorrectly configured as a standalone deployment.
This can happen because of a configuration error during a new installation or by rebooting the Security
Management server while it is still installing its initial policy.
To Change a Security Management server that is Incorrectly Configured as a Standalone
Deployment:
1. Run cpprod_util FwIsFireWallModule. If the output value is 1, the Security Management server
is incorrectly configured as a standalone deployment. Continue with this procedure.
2. Run fw unloadlocal to unload the policy from the Security Management server.
3. Run cpprod_util FwSetFireWallModule 0 to disable the Security Gateway on this computer.
4. Reboot the computer.
The Security Management server is not in

the Listening State
To Make Sure that the Security Management server is Listening on Port 257 (the Check
Point Logging Port):
1. Run netstat na on the Security Gateway. If the Security Gateway is listening on port 257, the output
should look similar to this example:
TCP 10.1.1.13:257 10.1.1.2:2085 ESTABLISHED
TCP 10.1.1.13:257 10.1.1.3:1133 ESTABLISHED
tcp 0 0 10.1.1.2.2085 10.1.1.13.257 ESTABLISHED
In this example, the Security Management server (10.1.1.13) is listening to two Security Gateways
(10.1.1.2, 10.1.1.3) on port 257. These two Security Gateways are in the LISTENING state and are
sending logs.
Network Connectivity
To Make Sure that you Have Basic Network Connectivity:
1. Ping the Security Gateways from the Security Management server and the Security Management server
from the Security Gateways.
2. Make that your firewall rules allow connectivity between the Security Gateways, intermediate Security
Gateways and the Security Management server.
3. Make sure that you have connectivity over port 257 and that firewall rules are not blocking this port. You
can run telnet mgmt_ip_address 257 to do this verification.
If you cannot ping or use telnet successfully, the traffic is probably being dropped or is incorrectly routed.
You can use SmartView Tracker to identify dropped traffic or tcpdump ("Using tcpdump to Verify Network
Connections" on page 7) to troubleshoot routing issues.

Installing a Policy
Installing a Policy
Make sure that you can install a policy on, or fetch a policy from the Security Gateway. If you cannot install
or fetch a policy, make sure that SIC trust is operational between the Security Gateway and the Security
Management server. Try reconfiguring SIC Trust.
To fetch a policy from the Security Management server, run fw fetch <Security Management
server host name or IP address>.
Making Sure that Logs are Sent

If the log file is growing in size, it is likely that log files are not being sent to the Security Management server
or the log server. To see if this is true, run these commands:
cd $FWDIR/log
ls -la
Run netstat -an | grep 257 to show if the connection is established, but localhost destination is
configured as the Security Gateway instead of the Security Management server or the log server IP
address.
Verifying the Masters File

Make sure that the masters file (%FWDIR/conf/masters) contains the correct host name or IP address for
the Security Management server or log server. The file should look similar to this:
fw[admin]# cat $FWDIR/conf/masters
[Policy]
hostage_of_FW
[Log]
hostage_of_FW
[Alert]
hostage_of_FW
If the host name or IP address does not match that of the Security Management server or the log server,
you must correct this.
Using tcpdump to Verify Network

Connections
This procedure lets you verify network connections between the Security Gateways and the Security
Management server or log server.
To make sure that the gateway can send logs to the Security Gateway, run this command:
tcpdump -i <interface connected to Security Management server> port 257
To make sure that Security Management server can receive logs from the Security Gateway:
tcpdump -i <interface connected to gateways> port 257
You should see that the packet going from the Security Gateway is received by the Security Management
server. Likewise, with the second command, you should see a packet going from the Security Management
server to the Security Gateway.
tcpdump on interface connected to the Security Management server that is listening to port 257. This also
shows the IP address that the Security Gateway is trying to send traffic to and from.
If you cannot see the packet going from one side to the other, do the network connectivity (on page 6)
procedure.

Doing a Log Switch
Doing a Log Switch

Run fw logswitch on the Security Management server and then reboot the computer. If this does not
resolve the issue, move the contents of the log directory ($FWDIR/log) to a temporary directory.
· Make sure that you do not copy the log directory itself.
· Make sure that the temporary directory is not a subdirectory of the log directory.
Reboot the computer and then check the logs.
Removing Possible Corrupted Files

To Remove Possible Corrupted Files:
1. Backup and then delete all log files ($FWDIR/log) on the Security Gateway.
2. Reboot the Security Gateway.
3. Look at the logs.
Using Debug
If none of these procedures helped you to resolve the issue, you can use the debug command to collect
troubleshooting information. We recommend that you use debug with the fwd and cpd process on the
Security Gateways and the Security Management server. Debugging the cpd process is useful for resolving
SIC trust issues.
Suggested Workflow for Using Debug:
1. Run debug on the Security Gateway.
cpd_admin debug on TDERROR_ALL_ALL=5
fw debug fwd on TDERROR_ALL_ALL=5
2. Run debug on the Security Gateway.
cpd_admin debug on TDERROR_ALL_ALL=5
fw debug fwm on TDERROR_ALL_ALL=5
fw debug fwd on TDERROR_ALL_ALL=5
3. Let debug run for 1 to 2 minutes and then stop the debug.
cpd_admin debug off TDERROR_ALL_ALL=1
fw debug fwm off TDERROR_ALL_ALL=1
fw debug fwd off TDERROR_ALL_ALL=1
4. Run cpinfo on the Security Gateways and the Security Management server. See sk30567
(http://supportcontent.checkpoint.com/solutions?id=sk30567) to get instructions for downloading and
installing cpinfo.
5. Send this information to customer support.
Verification
After each procedure, run SmartView Tracker to see if logs are received correctly from the Security
Gateways.
Verification Page 8
Index
D
Doing a Log Switch • 8
H
How To Troubleshoot Logging Issues • 5
I
Impact on the Environment and Warnings • 5
Incorrectly Configured Standalone Deployments
•6
Installing a Policy • 7
M
Making Sure that Logs are Sent • 7
N
Network Connectivity • 6
O
Objective • 5
P
Preliminary Questions • 5
R
Removing Possible Corrupted Files • 8
S
Supported Appliances • 5
Supported Operating Systems • 5
Supported Versions • 5
T
The Security Management server is not in the
Listening State • 6
Troubleshooting Procedures • 5
U
Using Debug • 8
Using tcpdump to Verify Network Connections •
7
V
Verification • 8
Verifying the Masters File • 7
How to Troubleshoot
Identity Awareness Issues
18 September 2011
without notice.
52.227-19.
TRADEMARKS:
Latest Software
Revision History
Date Description
18 September 2011 First release of this document
Feedback
(mailto:cp_techpub_feedback@checkpoint.com?subject=Feedback on How to Troubleshoot Identity
Awareness Issues ).
Contents

How to Troubleshoot Identity Awareness Issues .................................................5
Objective .................................................................................................................5
Impact on the Environment and Warnings ........................................................... 5
Supported OS...................................................................................................... 5
Before You Start .....................................................................................................5
Related Documentation ....................................................................................... 5
Assumed Knowledge ........................................................................................... 5
Troubleshooting General AD Integration ..............................................................6
User Groups and Access Roles are Not Enforced or Logged .............................. 6
Users Fail to Authenticate.................................................................................... 6
Troubleshooting AD Query ....................................................................................6
Users are Not Detected ....................................................................................... 6
AD Query Fails to Connect to Domain Controllers ............................................... 7
Not All Users are Detected .................................................................................. 7
Small Number of Users are Detected .................................................................. 7
A Service User is Connected to an IP Address .................................................... 7
Multiple Users are Connected to Same IP Address ............................................. 8
SmartView Tracker User Name and Group Membership Error Messages ........... 8
Troubleshooting Identity Awareness Configuration Wizard ................................8
SmartDashboard Fails to Connect ....................................................................... 8
WMI (DCE-RPC) Test Failed ............................................................................... 8
LDAP Connectivity Failed .................................................................................... 9
Using the Wizard Again to Create Other Domains ............................................... 9
Login DN and AD Forest Errors ........................................................................... 9
Troubleshooting Access Roles............................................................................10
Domain Users or Groups Do Not Appear in the List............................................10
Slow AD Tree .....................................................................................................10
Troubleshooting Captive Portal ...........................................................................10
Server Not Found or a Clear Screen ..................................................................10
Endless Redirect Loop .......................................................................................11
Portal Enters a Loop when Agent is Connected..................................................12
Client IP Address Identified Incorrectly ...............................................................12
Cannot Authenticate With Correct Credentials....................................................12
Changes in Portal Settings are Not Seen ...........................................................12
Identity Agent is Installed But Get the Captive Portal ..........................................13
Captive Portal Bad Appearance..........................................................................13
Troubleshooting Identity Agent ...........................................................................13
Agent Fails to Connect to Server ........................................................................13
Kerberos Does Not Work ....................................................................................14
Kerberos Does Not Work for All Users................................................................14
Kerberos Does Not Work for One User...............................................................14
Troubleshooting Distributed Environments ....................................................... 15
User Access Based on Identity Agent Works But Not AD Query.........................15
Identities are Not Propagated to the Identity Server............................................15
Index ...................................................................................................................... 17
How to Troubleshoot Identity

Awareness Issues
Objective
This document explains how to troubleshoot Identity Awareness issues.
Identity Awareness lets you easily configure in SmartDashboard network access and auditing based on
network location and:
· The identity of a user
· The identity of a machine
When Identity Awareness identifies a source or destination, it shows the IP address of the user or machine
with a name.

· Check Point R75 and higher
Supported OS
· SecurePlatform
· IPSO
· UTM-270 and higher
Before You Start

Related Documentation
· R75 Identity Awareness Administration Guide
(http://supportcontent.checkpoint.com/documentation_download?ID=11662)
· R75.20 Identity Awareness Administration Guide
Assumed Knowledge
· Use of Identity Awareness
· Use of Active Directory
How to Troubleshoot Identity Awareness Issues Page 5

User Groups and Access Roles are Not Enforced or Logged
Troubleshooting General AD
Integration
User Groups and Access Roles are Not
Enforced or Logged
Issue
Users are identified successfully, but their user groups and Access Roles are not enforced or logged
correctly.
Solution
1. Make sure that there is one LDAP Account Unit for each AD domain. If you must configure domain
controllers for each gateway (for AD Query for example), see the Advanced AD Query section in the
R75.20 Identity Awareness Administration Guide
(http://supportcontent.checkpoint.com/documentation_download?ID=12268).
2. If the configured user group is the primary group for the user account, there is no solution. Workaround:
Change the AD account to be a member of the group.
Users Fail to Authenticate

Issue
Users fail to authenticate in Captive Portal or Identity Agent and the user name and password are correct.
Solution
1. Make sure that the user's account is not locked or expired.
2. If there are multiple accounts with the same user name, the AD user must authenticate with
domain\user. For example, CORP.ACME.COM\jdoe.
This can occur in organizations with multiple AD domains or in an AD domain and internal user
database.
Troubleshooting AD Query
Users are Not Detected
Issue
AD Query is connected successfully to all domain controllers, but users are not detected. Furthermore, there
are some events in SmartView Monitor.
Solution
Make sure that the necessary auditing logs are generated on the Security Event log of the domain
controllers.
· On 2003 domain controllers the events are 672, 673, and 674.
· On 2008 domain controllers the events are 4624, 4768, 4769, and 4770.
Troubleshooting General AD Integration Page 6

AD Query Fails to Connect to Domain Controllers
AD Query Fails to Connect to Domain

Controllers
Issue
AD Query fails to connect to the domain controllers. You can see this in SmartView Tracker, SmartView
Monitor or you can run adlog a dc in expert mode.
Solution
See sk58881 (http://supportcontent.checkpoint.com/solutions?id=sk58881).
Not All Users are Detected

Issue
Not all users are detected.
Solution
AD Query must be configured to communicate with the actual domain controller that the user is connected
to. This is necessary because security event logs are not replicated.
Make sure that the domain controller that the user is connected to belongs to the AD Query account unit.
You can use echo %LOGONSERVER%
If AD Query was configured through the wizard and the SmartDashboard computer is not a member of the
domain, then only one domain controller is entered into the LDAP Account unit.
Small Number of Users are Detected

Issue
AD Query is successfully connected to the domain controllers and receives events, but the number of users
detected is relatively low. Numbers detected can be seen in SmartView Monitor or with adlog a query
all.
Solution
1. Make sure that users / IP addresses are not ignored. You can configure this in SmartDashboard.
2. Make sure that users do not go through a NAT (with Check Point NAT) to the firewall. If the events in the
security event log are generated with a NAT IP address, they will be ignored automatically.
NAT is not supported by AD Query.
A Service User is Connected to an IP

Address
Issue
AD Query shows that a different user is connected to a user's IP address. This can be a service user (for
example, an anti virus company name) that is connected besides the actual user.
Solution
AD Query does not know the difference between an actual user that logged in and a service account that
logged in from the same computer. You can filter service accounts in SmartDashboard.
To learn more about filtering service accounts, see the R75.20 Identity Awareness Administration Guide
Troubleshooting AD Query Page 7

Multiple Users are Connected to Same IP Address
Multiple Users are Connected to Same IP

Address
Issue
After a user logs off and a different user logs on, AD Query still thinks that both users are connected.
Solution
AD Query aggregates users and permissions. Only after the first user's session is timed out, the user's
session is revoked. To change this behavior, you can configure the Assume only one user per machine
option in SmartDashboard. This option requires that you also ignore the service account.
To learn more about assuming only one user for a machine, see the R75.20 Identity Awareness
Administration Guide (http://supportcontent.checkpoint.com/documentation_download?ID=12268).
SmartView Tracker User Name and Group

Membership Error Messages
Issue
SmartView Tracker error messages show that the gateway could not fetch group membership for users and
the user names contain non-English characters.
Solution
In GuiDBedit, enable the EnableUnicode attribute on the LDAP account unit.
See the R75.20 Identity Awareness Administration Guide
Troubleshooting Identity Awareness

Configuration Wizard
SmartDashboard Fails to Connect
Issue
The Identity Awareness Configuration Wizard fails to open. A message states that "SmartDashboard failed
to connect to..". The error message starts with SmartDashboard and not gateway.
Solution
WMI (DCE-RPC) Test Failed

Issue
The Identity Awareness Configuration Wizard fails. An error message states WMI(DCE-RPC) test failed or
shows an equivalent message.
AD Query is configured, but users are not identified in logs and cannot get access based on their identity.
In SmartView Monitor or with the adlog a dc command line in Expert mode, you see domain controllers
that the Security Gateway fails to connect to.
Troubleshooting Identity Awareness Configuration Wizard Page 8

LDAP Connectivity Failed
Solution
LDAP Connectivity Failed

Issue
There are two parts to this issue:
1. The Identity Awareness Configuration Wizard fails stating that LDAP connectivity failed. This also occurs
when the administrator has selected a working account unit in it.
2. LDAP connectivity test fails without an obvious cause and only LDAP over SSL is supported on the
domain controllers.
Solution
The Identity Awareness Configuration Wizard works only with LDAP (not LDAPS). It disregards the use ssl
option on the account unit. If LDAP (as opposed to LDAPS) is disabled, the wizard fails and the
administrator needs to configure the account unit manually.
Using the Wizard Again to Create Other

Domains
Issue
An administrator wants to use the wizard again to create other domains.
Solution
Clear the Enable Identity Awareness checkbox in SmartDashboard and then select it again. This selection
will rerun the wizard.
Login DN and AD Forest Errors

Issue
Identity Awareness Configuration Wizard fails, possibly stating that it:
· Could not fill in the Login DN parameter in the LDAP Account Unit
· The customer Active Directory forest contains more than one Active Directory Domain
Solution
Learn more about configuring Identity Awareness for forests with more than one domain (usually
subdomains), see the R75.20 Identity Awareness Administration Guide
Troubleshooting Identity Awareness Configuration Wizard Page 9

Domain Users or Groups Do Not Appear in the List
Troubleshooting Access Roles

Domain Users or Groups Do Not Appear in
the List
Issue
There is a red X on the domain name and no domain users or groups are available in the list.
Solution
Make sure that SmartDashboard has a working connection to the domain controller.
Slow AD Tree
Issue
The AD tree is slow to show results.
Solution
This occurs when there are many sibling folders in the AD tree. There is no solution for this issue.
Troubleshooting Captive Portal

Server Not Found or a Clear Screen
Issue
Browsing to http://www.myIAServer.com/connect shows “Server Not Found” or a clear screen.
Solution
Make sure you configured Identity Awareness correctly:
· Did you enable Identity Awareness?
· Did you connect to the correct URL?
· Did you configure DNS?
· Did you define a rule and install policy?
Troubleshooting Access Roles Page 10

Endless Redirect Loop
· Did you connect to the correct interface?
· Is the portal up?

Make sure with:
[admin@cpmodule ~]$ mpclient status nac
Portal is not running
Endless Redirect Loop

Issue
There is an endless redirect loop when this environment is deployed.
Solution
1. Prevent this type of environment when possible.
2. Add the Captive Portal as an exception in the browser proxy settings.
Troubleshooting Captive Portal Page 11

Portal Enters a Loop when Agent is Connected
Portal Enters a Loop when Agent is

Connected
Issue
If a user is revoked from the system, the client machine can enter an endless loop when trying to browse to
a web site. The loop occurs since the gateway is redirecting to the Captive Portal and the Captive Portal
assumes that the agent is connected and directs the web browser to the original URL.
Solution
You should know about this problem. Don’t revoke an IP in this situation.
Client IP Address Identified Incorrectly

Issue
The client IP address is identified incorrectly.
Solution
All clients that go through the proxy are reported with the proxy IP address and not their own IP address.
Work with x-forwarded-for to:
· Make sure that the proxy is configured to send x-forwarded-for in its header.
· Make sure that APPI (Application Control) is running. APPI is the component that reads this header.
Cannot Authenticate With Correct

Credentials
Issue
You cannot authenticate with correct credentials.
Solution
1. Are your credentials in English only?
· If not – make sure you enabled the SupportUnicode field in the LDAP account unit server object
with GuiDBedit.
Use the GuiDBedit command:
modify servers <ldap_au_name> SupportUnicode 'true'
To learn more, see sk32030 (http://supportcontent.checkpoint.com/solutions?id=sk32030).
2. Make sure that pdpd is running.
3. Use domain\user when you have more than one account with the same name.
Changes in Portal Settings are Not Seen

Issue
After you customize portal images or other customization changes, you do not see the changes in the portal
or the web browser.
Troubleshooting Captive Portal Page 12

Identity Agent is Installed But Get the Captive Portal
Solution
1. Close and reopen ALL open browser windows (to make sure the browsing session no longer exists).
Browsing sessions that were open while changes were being made, continue to work with previous
settings.
2. Clear the browser cache.
Identity Agent is Installed But Get the

Captive Portal
Issue
The Identity Agent has been installed on my computer, but I keep getting the Captive Portal.
Solution
Make sure the Identity Agent is:
· Working
· Connected
· Authenticated
If you use an Internet Explorer browser, when you are connected and authenticated you are redirected to
your initial destination. Other browsers do not work like this.
Captive Portal Bad Appearance

Issue
The Captive Portal looks bad.
Solution
1. Make sure you are using a supported browser:
· Internet Explorer 6,7,8
· Safari 5
· Firefox 3
· Chrome 8
2. Reload the portal page in your browser
Troubleshooting Identity Agent

Agent Fails to Connect to Server
Issue
The umbrella icon on a user's computer is closed and the agent fails to connect to the server.
Solution
Do these steps until one works.
1. Try to configure the gateway manually.
2. Make sure the gateway's discovery configuration is correct.
Troubleshooting Identity Agent Page 13

Kerberos Does Not Work
3. If the problem is only for one computer, make sure the DNS settings and network configuration are
correct.
4. Reset Agent settings:
a) Double-click the umbrella icon.
b) Go to Advanced > Reset to defaults and try to connect.
5. Restart the service:
a) Open a command line with computer administrator credentials.
b) Enter sc stop madservice and then sc start madservice
6. If no users can connect with the Identity Agent, make sure the gateway uses an internal interface to
communicate with the client. It not, change this setting from Identity Awareness gateway properties >
Identity Agent Settings.
Kerberos Does Not Work

Issue
Kerberos does not work on this network.
Solution
1. Read the Kerberos section in the R75.20 Identity Awareness Administration Guide
(http://supportcontent.checkpoint.com/documentation_download?ID=12268) and do the steps carefully.
2. Make sure that you enter the KTPass command manually and not with copy and paste.
3. Make sure you have the same output.
4. If you did all of the steps and it never worked, delete the user and follow the steps in the R75.20 Identity
Awareness Administration Guide
Kerberos Does Not Work for All Users

Issue
Kerberos does not work for all users.
Solution
1. Make sure the date and time on the server is correct including daylight savings time.
2. Make sure the gateway Kerberos user is not locked out.
3. Reset the user password on the domain controller.
4. Make sure the account is not disabled.
Kerberos Does Not Work for One User

Issue
Kerberos Does Not Work for One User
Solution
1. Make sure the user’s time and date are synchronized with the Kerberos server and the Identity Server
(including Day Lights Saving).
2. Make sure the user is not locked out.
3. Make sure the user has a Kerberos ticket.
4. If you recently changed the gateway Kerberos user password, log out and then log in again.
Troubleshooting Identity Agent Page 14

User Access Based on Identity Agent Works But Not AD Query
Troubleshooting Distributed
Environments
User Access Based on Identity Agent
Works But Not AD Query
Issue
A user is authenticated based on Identity Agent but not with AD Query.
Solution
1. Make sure that AD Query is configured correctly (adlog utility).
2. Make sure the user is in the AD Query database using the adlog utility.
3. Make sure communication has been established between the Identity Server and Identity Gateway (use
pdp and pep commands).
4. If the user is in the AD Query database but is not in the Identity Gateway database (use pep show user
all)
a) Issue a "sync" between the Identity Server and Identity Gateway (use pdp control sync).
b) Make sure the user is in the Identity Gateway (use pep show user all).
Identities are Not Propagated to the Identity

Server
Issue
The Identity Server that is set to share identities is not getting identities.
Solution
1. Make sure that the daemons pepd and pdpd are up and running.
2. Make sure that the Identity Server is configured to connect to the Identity Gateway (run pdp c p on the
Identity Server).
3. Make sure that communication is possible to the main IP address of the remote gateway in both
directions. Do this with a ping from one gateway to the other gateway's main IP. If you are testing
connectivity from the Identity Server, then the remote gateway is the Identity Gateway and vice-versa.
4. If communication is not possible through the main IP address, use sk60701
(http://supportcontent.checkpoint.com/solutions?id=sk60701). This instructs you how to change the IP
address used for the communication channel.
Troubleshooting Distributed Environments Page 15

P
Portal Enters a Loop when Agent is Connected
Index • 12
R
A Related Documentation • 5
A Service User is Connected to an IP Address •
7
S
AD Query Fails to Connect to Domain Server Not Found or a Clear Screen • 10
Controllers • 7 Slow AD Tree • 10
Agent Fails to Connect to Server • 13 Small Number of Users are Detected • 7
Assumed Knowledge • 5 SmartDashboard Fails to Connect • 8
SmartView Tracker User Name and Group
B Membership Error Messages • 8
Before You Start • 5 Supported Appliances • 5
Supported OS • 5
C
T
Cannot Authenticate With Correct Credentials •
12 Troubleshooting Access Roles • 10
Captive Portal Bad Appearance • 13 Troubleshooting AD Query • 6
Changes in Portal Settings are Not Seen • 12 Troubleshooting Captive Portal • 10
Client IP Address Identified Incorrectly • 12 Troubleshooting Distributed Environments • 14
Troubleshooting General AD Integration • 6
D Troubleshooting Identity Agent • 13
Domain Users or Groups Do Not Appear in the Troubleshooting Identity Awareness
List • 10 Configuration Wizard • 8
E U
Endless Redirect Loop • 11 User Access Based on Identity Agent Works
But Not AD Query • 15
H User Groups and Access Roles are Not
Enforced or Logged • 6
How to Troubleshoot Identity Awareness Issues Users are Not Detected • 6
•5 Users Fail to Authenticate • 6
I Using the Wizard Again to Create Other
Domains • 9
Identities are Not Propagated to the Identity
Server • 15 W
Identity Agent is Installed But Get the Captive WMI (DCE-RPC) Test Failed • 8
Portal • 13
Impact on the Environment and Warnings • 5
K
Kerberos Does Not Work • 14
Kerberos Does Not Work for All Users • 14
Kerberos Does Not Work for One User • 14
L
LDAP Connectivity Failed • 9
Login DN and AD Forest Errors • 9
M
Multiple Users are Connected to Same IP
Address • 8
N
Not All Users are Detected • 7
O
Objective • 5
Performance Tuning
R77
Administration Guide
7 May 2015
Classification: [Protected]
without notice.
52.227-19.
TRADEMARKS:
Latest Software
To learn more, visit the Check Point Support Center (http://supportcenter.checkpoint.com).
For more about this release, see the R77 home page
(http://supportcontent.checkpoint.com/solutions?id=sk92965).
Revision History
Date Description
07 May 2015 Removed unncessary reference to drop template support. ("Deciding if

Multi-Queue is needed" on page 33).
11 June 2014 Cover changed to be relevant for all R77 versions.
01 January 2013 More multi-queue troubleshooting added ("Troubleshooting" on page 41).

Disabling multi-queue update. ("Special Scenarios and Configurations" on
page 40)
Corrected:
Special Scenarios and Configurations (on page 40)
Deciding if Multi-queue is needed (on page 33)
Basic Multi-queue Configuration (on page 36)
Feedback
(mailto:cp_techpub_feedback@checkpoint.com?subject=Feedback on Performance Tuning R77
Administration Guide).
Contents
Important Information............................................................................................................ 3
Terms...................................................................................................................................... 7
Performance Pack.................................................................................................................. 8
Introduction to Performance Pack........................................................................................ 8
Supported Features ........................................................................................................ 8
Preparing the Performance Pack .................................................................................... 9
Installing during a SecurePlatform Gateway Installation.................................................. 9
Installing on SecurePlatform Gateway ............................................................................ 9
Installing on Installed SecurePlatform Gateway with HFA............................................... 9
Upgrading with SmartUpdate ........................................................................................ 10
Upgrading with the Command Line ............................................................................... 10
Command Line .................................................................................................................. 10
fwaccel ......................................................................................................................... 10
fwaccel6........................................................................................................................ 11
fwaccel stats and fwaccel6 stats ................................................................................... 13
cpconfig ........................................................................................................................ 15
sim affinity..................................................................................................................... 15
proc entries................................................................................................................... 16
Performance Tuning and Measurement............................................................................. 16
Setting the Maximum Concurrent Connections ............................................................. 16
Increasing the Number of Concurrent Connections....................................................... 16
SecureXL Templates .................................................................................................... 16
SecureXL NAT templates ............................................................................................. 17
Delayed Notification...................................................................................................... 17
Connection Templates .................................................................................................. 17
Delayed Synchronization .............................................................................................. 18
Multi-Core Systems ...................................................................................................... 18
Performance Measurement........................................................................................... 19
CoreXL Administration........................................................................................................ 20
Supported Platforms and Unsupported Features............................................................... 20
Default Configuration......................................................................................................... 21
CoreXL for IPv6................................................................................................................. 21
Configuring IPv4 and IPv6 Firewall Instances.................................................................... 21
Performance Tuning .......................................................................................................... 23
Processing Core Allocation ........................................................................................... 23
Allocating Processing Cores ......................................................................................... 23
Performance Tuning .......................................................................................................... 26
Processing Core Allocation ........................................................................................... 26
Allocating Processing Cores ......................................................................................... 26
Configuring CoreXL ........................................................................................................... 29
Command Line Reference................................................................................................. 29
Affinity Settings ............................................................................................................. 29
fwaffinity.conf ................................................................................................................ 29
fwaffinty_apply .............................................................................................................. 30
fw ctl affinity .................................................................................................................. 30
fw ctl multik stat ............................................................................................................ 32
Multi-Queue.......................................................................................................................... 33
Introduction to Multiple Traffic Queues .............................................................................. 33
Multi-Queue Requirements and Limitations .................................................................. 33
Deciding if Multi-Queue is needed ................................................................................ 33
Basic Multi-Queue Configuration ....................................................................................... 36
Multi-Queue Administration ............................................................................................... 37
Advanced Multi-Queue settings ......................................................................................... 38
Adding more Interfaces................................................................................................. 40
Special Scenarios and Configurations ............................................................................... 40
Troubleshooting................................................................................................................. 41
Index ..................................................................................................................................... 43
Terms
Affinity
The assignment of a specified process, Firewall
instance, VSX Virtual System, interface or IRQ
with one or more CPU cores.
CoreXL
A performance-enhancing technology for Security
Gateways on multi-core processing platforms.
Firewall Instance
On a Security Gateway with CoreXL enabled, the
Firewall kernel is replicated multiple times. Each
replicated copy, or firewall instance, runs on one
processing core. These instances handle traffic
concurrently, and each instance is a complete
and independent inspection kernel.
IPv4
Internet Protocol Version 4 IP address. A 32-bit
number - 4 sets of numbers, each set can be from
0 - 255.
IPv6
Internet Protocol Version 6 IP address. 128-bit
number - 8 sets of hexadecimal numbers, each
set can be from 0 - ffff.
IRQ Affinity
A state of binding an IRQ to one or more CPUs.
Multi-queue
An acceleration feature that lets you assign more
than one packet queue and CPU to an interface.
Rx Queue
Receive packet queue
SND
Secure Network Distributor. A CPU that runs
SecureXL and CoreXL.
Traffic
The flow of data between network resources.
Tx queue
Transmit packet queue
Chapter 1
Performance Pack
In This Section:
Introduction to Performance Pack............................................................................. 8
Command Line........................................................................................................ 10
Performance Tuning and Measurement ................................................................. 16
Introduction to Performance Pack

Performance Pack is a software acceleration product installed on Security Gateways. Performance Pack
uses SecureXL technology and other innovative network acceleration techniques to deliver wire-speed
performance for Security Gateways.
Performance Pack is supported on:
‚ SecurePlatform
‚ To install SecureXL, run: sysconfig
‚ To enable SecureXL, run: cpconfig
‚ Gaia
‚ On Gaia, Performance Pack is automatically installed when you run the First Time Wizard.
‚ To enable SecureXL, run: cpconfig
Supported Features
These security functions are enhanced by Performance Pack:
‚ Access control
‚ Encryption
‚ NAT
‚ Accounting and logging
‚ Connection/session rate
‚ General security checks
‚ IPS features
‚ CIFs resources
‚ ClusterXL High Availability and Load Sharing
‚ TCP Sequence Verification
‚ Dynamic VPN
‚ Anti-Spoofing verifications
‚ Passive streaming
‚ Drop rate
Performance Tuning Administration Guide R77 | 8

Performance Pack
Preparing the Performance Pack

For optimal performance, configure the BIOS and NICs for Performance Pack.
BIOS Settings
‚ If your BIOS supports CPU clock setting, make sure that the BIOS is set to the actual CPU speed.
‚ For Hyper-threading, see sk93000 (http://supportcontent.checkpoint.com/solutions?id=sk93000).
Network Interface Cards

‚ If you are using a motherboard with multiple PCI or PCI-X buses, make sure that each Network Interface
Card is installed in a slot connected to a different bus.
‚ If you are using more than two Network Interface Cards in a system with only two 64bit/66Mhz PCI
buses, make sure that the least-used cards are installed in slots connected to the same bus.
For an updated list of certified Network Interface Cards, see Certified Network Interfaces
(http://www.checkpoint.com/services/techsupport/hcl/nic/).
Note - Performance Pack is automatically disabled on PPTP and PPPoE interfaces
Installing during a SecurePlatform Gateway Installation

During the Check Point SecurePlatform installation process, select the following products from the list of
products to install:
‚ Security Gateway
‚ Performance Pack
Installing on SecurePlatform Gateway

Performance Pack can be installed on a Security Gateway on SecurePlatform.
1. Type sysconfig to enter the configuration menu.
2. Select Products Installation.
3. Follow the instructions until reaching the product selection screen.
4. Select Performance Pack.
5. Follow the instructions until finish.
6. Exit the configuration menu.
7. Reboot the gateway.
Installing on Installed SecurePlatform Gateway with HFA

If the SecurePlatform Security Gateway has a customer release, minor release, Hotfix, or Hotfix accumulator
(HFA) installed on top of the main gateway version, use these steps.
1. Type sysconfig to enter the configuration menu.
2. Select Products Installation.
3. Follow the instructions until reaching the product selection screen.
4. Select Performance Pack.
5. Follow the instructions until finish.
6. Select Products Configuration.
7. Disable Check Point SecureXL.
8. Exit the configuration menu.
10. Upgrade the Performance Pack using SmartUpdate or from command line.

Performance Pack
Upgrading with SmartUpdate

We recommend that you use SmartUpdate to upgrade Performance Pack.
To upgrade with SmartUpdate:

1. Select SmartUpdate from Check Point SmartConsole.
2. From the Packages menu, select Add > From File….
3. Select the HFA package and wait until the uploading finished.
4. From the Package Repository, select the Performance Pack package and drag it to the appropriate
gateway.
5. Follow the instructions until finished.
Upgrading with the Command Line

If SmartUpdate is not an option, you can update with the command line.
1. Change to the directory where the upgrade file (.tgz) is located.
2. Run: tar –xzvf <filename>
3. Change to the CPppak directory.
4. Run: tar –xzvf <sim filename>
5. Run the sim executable.
Command Line
fwaccel
Description Lets you dynamically enable or disable acceleration for IPv4 traffic while a Security
Gateway is running. The fwaccel6 has the same functionality for IPv6 traffic. The default
setting is determined by the setting configured with cpconfig. This setting reverts to the
default after reboot.
Works with the IPv4 kernel.
fwaccel [on|off|stat|stats|conns|templates]
Syntax

Performance Pack
Parameters Parameter Description

on Starts acceleration
off Stops acceleration
stat Shows the acceleration device status and the status of the
Connection Templates on the local Security Gateway.
stats Shows acceleration statistics.
stats -s Shows more summarized statistics.
stats -d Shows dropped packet statistics.
conns Shows all connections.
conns -s Shows the number of connections defined in the accelerator.
conns -m Limits the number of connections displayed by the conns command

max_entries to the number entered in the variable max_entries.
templates Shows all connection templates.
templates -m Limits the number of templates displayed by the templates

max_entries command to the number entered in the variable max_entries.
templates -s Shows the number of templates currently defined in the accelerator.
fwaccel6
Description Lets you enable or disable acceleration dynamically while a Security Gateway is running.
The default setting is determined by the setting configured using cpconfig. This setting
goes back to the default after reboot.
Works with the IPv6 kernel.
Syntax fwaccel6 [on|off|stat|stats|conns|templates]

Performance Pack
Parameters Parameter Explanation

on Starts IPv6 acceleration.
off Stops IPv6 acceleration.
stat Shows the acceleration device status and the status of the
stats Shows summary acceleration statistics.
stats -s Shows detailed summarized statistics.
conns Shows all IPv6 connections.
conns -s Shows the number of IPv6 connections currently defined in the

accelerator.
conns -m Lowers the number of IPv6 connections shown by the conns

<max_entries command to the number entered in the variable max_entries.
>
templates Shows all IPv6 connection templates.
templates -m Lowers the number of templates shown by the templates

max_entries command to the number entered in the variable max_entries.
templates -s Shows the number of templates currently defined for the

accelerator.
Example: fwaccel6 stat

Description The fwaccel6 stat command displays the acceleration device status and the status of the
Example fwaccel6 stat -all
Output
Accelerator Status : on
Accept Templates : enabled
Accelerator Features : Accounting, NAT, Routing, HasClock, Templates,
Synchronous, IdleDetection, Sequencing, TcpStateDetect, AutoExpire,
DelayedNotif, TcpStateDetectV2, CPLS, WireMode, DropTemplates
Example: fwaccel6 templates

Description The fwaccel6 templates command displays all the connection templates
Example fwaccel6 templates

Source SPort Destination DPort PR Flags LCT DLY C2S i/f S2C i/f
Output
--------------------------------------- -----
--------------------------------------- ----- -- ------- ----
--- --------- ---------
9999:b:0:0:0:0:0:10 * 9999:b:0:0:0:0:0:20 10000 17 ....... 15 0
Lan5/Lan1 Lan1/Lan5

Performance Pack
Example: fwaccel6 stats

Description The fwaccel6 stats command displays acceleration statistics
Example fwaccel6 stats

Name Value Name Value
Output
-------------------- ---------------
-------------------- ---------------
conns created 11 conns deleted 7
temporary conns 0 templates 1
nat conns 0 accel packets 2
accel bytes 96 F2F packets 39
ESP enc pkts 0 ESP enc err 0
ESP dec pkts 0 ESP dec err 0
ESP other err 0 espudp enc pkts 0
espudp enc err 0 espudp dec pkts 0
espudp dec err 0 espudp other err 0
AH enc pkts 0 AH enc err 0
AH dec pkts 0 AH dec err 0
AH other err 0 memory used 0
free memory 0 acct update interval 3600
current total conns 4 TCP violations 0
conns from templates 0 TCP conns 0
delayed TCP conns 0 non TCP conns 4
delayed nonTCP conns 0 F2F conns 3
F2F bytes 2848 crypt conns 0
enc bytes 0 dec bytes 0
partial conns 0 anticipated conns 0
dropped packets 0 dropped bytes 0
nat templates 0 port alloc templates 0
conns from nat tmpl 0 port alloc conns 0
port alloc f2f 0
fwaccel stats and fwaccel6 stats

The fwaccel stats and fwaccel6 stats commands show performance statistics. This information
can help you understand traffic behavior and help investigate performance issues.
Statistic parameter Explanation
conns created Number of created connections
conns deleted Number of deleted connections
temporary conns Number of temporary connections
templates Number of templates currently handled
nat conns Number of NAT connections
accel packets Number of accelerated packets
accel bytes Number of accelerated traffic bytes
F2F packets Number of packets handled by the VPN kernel in slow-path
ESP enc pkts Number of ESP encrypted packets
ESP enc err Number of ESP encrypted errors

Performance Pack
ESP dec pkts Number of ESP decrypted packets
ESP dec err Number of ESP decrypted errors
ESP other err Number of ESP other general errors
espudp enc pkts Not in use
espudp enc err Not in use
espudp dec pkts Not in use
espudp dec err Not in use
espudp other err Not in use
AH enc pkts Not in use
AH enc err Not in use
AH dec pkts Not in use
AH dec err Not in use
AH other err Not in use
memory used Not in use
free memory Not in use
acct update interval Accounting update interval in seconds
current total conns Number of connections currently handled
TCP violations Number of packets which are in violation of the TCP state
conns from templates Number of connections created from templates
TCP conns Number of TCP connections currently handled
delayed TCP conns Number of delayed TCP connections currently handled
non TCP conns Number of non TCP connections currently handled
delayed nonTCP conns Number of delayed non TCP connections currently handled
F2F conns Number of connections currently handled by the VPN kernel

in slow-path
F2F bytes Number of traffic bytes handled by the VPN kernel in slow-
path
crypt conns Number of encrypted connections currently handled
enc bytes Number of encrypted traffic bytes
dec bytes Number of decrypted traffic bytes

Performance Pack
partial conns Number of partial connections currently handled
anticipated conns Number of anticipated connections currently handled
dropped packets Number of dropped packets
dropped bytes Number of dropped traffic bytes
nat templates Not in use
port alloc templates Not in use
conns from nat tmpl Not in use
port alloc conns Not in use
port alloc f2f Not in use
PXL templates Number of PXL templates
PXL conns Number of PXL connections
PXL packets Number of PXL packets
PXL bytes Number of PXL traffic bytes
PXL async packets Number of PXL packets handled asynchronously
cpconfig
Check Point products are configured using the cpconfig utility. This utility shows the configuration options of
the installed configuration and products. You can use cpconfig to enable or disable Performance Pack.
When you select an acceleration setting, the setting remains configured until you change it.
For an alternative method to enable or disable acceleration, see fwaccel (on page 10).
Run: cpconfig
A menu shows Enable/Disable Check Point SecureXL.
sim affinity
Description The sim affinity utility controls various Performance Pack driver features for
SecurePlatform and Gaia.
Affinity is a general term for binding Network Interface Card (NIC) interrupts to processors.
By default, SecurePlatform does not set Affinity to the NIC interrupts. Therefore, each NIC
is handled by all processors. For optimal network performance, make sure each NIC is
individually bound to one processor.
sim affinity [-a|-s|-l]
Syntax

Performance Pack

-a Automatic Mode — (default) Affinity is determined by analysis of the
load on each NIC. If a NIC is not activated, Affinity is not set. NIC load
is analyzed every 60 seconds.
-s Manual Mode — Configure Affinity settings for each interface: the

processor numbers (separated by space) that handle this interface, or
all. In Manual Mode, periodic NIC analysis is disabled.
-l See Affinity settings.
proc entries
Description Performance Pack supports proc entries. These read-only entries show data about
Performance Pack. The proc entries are in /proc/ppk.
cat /proc/ppk/[conf|ifs|statistics|drop_statistics]
Syntax

conf Shows Performance Pack configuration.
ifs Shows the interfaces to which Performance Pack is attached.
statistics Shows general Performance Pack statistics.
drop_statistics Shows Performance Pack dropped packet statistics.
Performance Tuning and Measurement

Setting the Maximum Concurrent Connections
To set the number of maximum concurrent connections:
In SmartDashboard:
1. Open the Gateway Object Properties window.
2. Open the Capacity Optimization tab. Make sure that Calculate connections hash table size and
memory pool is set to Automatically.
3. Set the desired amount of concurrent connections in the Maximum Concurrent Connections field.
Increasing the Number of Concurrent Connections

You can increase the actual number of concurrent connections by reducing the timeout of TCP and UDP
sessions:
‚ TCP end timeout determines the amount of time a TCP connection will stay in the Firewall connection
table after a TCP session has ended.
‚ UDP virtual session timeout determines the amount of time a UDP connection will stay in the Firewall
connection table after the last UDP packet was seen by the gateway.
By reducing the above values, the capacity of actual TCP and UDP connections is increased.
SecureXL Templates
Verify that templates are not disabled using the fwaccel stat command.
For further information regarding SecureXL Templates, see sk32578
Performance Pack
SecureXL NAT templates

Using SecureXL Templates for NAT traffic lets you achieve a high session rate for NAT traffic. SecureXL
NAT Templates are supported in cluster in High Availability, VRRP, and Load Sharing modes.
For more, see: sk71200 (http://supportcontent.checkpoint.com/solutions?id=sk71200 ).
Delayed Notification
In the ClusterXL configuration, the Delayed Notification feature is disabled by default. Enabling this feature
improves performance (at the cost of connections' redundancy, which can be tuned using delayed
notifications expiration timeout).
The fwaccel stats command indicates the number of delayed connections.
The fwaccel templates command indicates the delayed time for each template under the DLY entry.
Connection Templates
Connection templates are generated from active connections according to the policy rules. The connection
template feature accelerates the speed at which a connection is established by matching a new connection
to a set of attributes. When a new connection matches the template, connections are established without
performing a rule match and therefore are accelerated. Connection templates are generated from active
connections according to policy rules. Currently, connection template acceleration is performed only on
connections with the same destination port.
Examples:
‚ A connection from 10.0.0.1/2000 to 11.0.0.1/80 — established through Firewall and then accelerated.
‚ A connection from 10.0.0.1/2001 to 11.0.0.1/80 — fully accelerated (including connection
establishment).
‚ A connection from 10.0.0.1/8000 to 11.0.0.1/80 — fully accelerated (including connection
establishment).
HTTP GET requests to specific server will be accelerated since the connection has the same source IP
address.
Restrictions
In general, Connections Templates will be created only for plain UDP or TCP connections. The following
restrictions apply for Connection Template generation:
Global restrictions:
‚ SYN Defender — Connection Templates for TCP connections will not be created
‚ VPN connections
‚ Complex connections (H323, FTP, SQL)
‚ NetQuotas
‚ ISN Spoofing
If the Rule Base contains a rule regarding one of the following components, the Connection Templates will
be disabled for connections matching this rule, and for all of the following rules:
‚ Security Server connections.
‚ Time objects in the rules.
‚ Dynamic Objects and/or Domain Objects.
‚ Services of type "other" with a match expression.
‚ User/Client/Session Authentication actions.
‚ Services of type RPC/DCERPC/DCOM.
Performance Pack
When installing a policy containing restricted rules, you will receive console messages indicating that
Connection Templates will not be created due to the rules that have been defined. The warnings should be
used as a recommendation that will assist you to fine-tune your policy in order to optimize performance.
Testing
To verify that connection templates are enabled, use the fwaccel stat command. To verify that connection
templates are generated, use fwaccel templates. This should be done while traffic is running, in order to
obtain a list of currently defined templates.
Delayed Synchronization
The synchronization mechanism guarantees High Availability. In a cluster configuration, if one cluster
member fails, the other recognizes the connection failure and takes over, so the user does not experience
any connectivity issue. However, there is an overhead per synchronized operation, which can occasionally
cause a system slow-down when there are short sessions.
Delayed synchronization is a mechanism based upon the duration of the connection, with the duration itself
used to determine whether or not to perform synchronization. A time range can be defined per service. The
time range indicates that connections terminated before a specified expiration time will not be synchronized.
As a result, synchronized traffic is reduced and overall performance increases. Delayed Synchronization is
performed only for connections matching a connection template.
Note - Delayed synchronization is disabled if the log or account are enabled
Currently, delayed synchronization is allowed only for services of type HTTP or None. In order to configure
delayed synchronization, proceed as follows:
1. In SmartDashboard, right click on the Service tab.
2. Either edit an existing service or click New and select TCP. The TCP service properties window is
shown.
3. After defining TCP parameters, click Advanced in the TCP service properties window. The Advanced
TCP Service Properties window is shown.
4. Select the HTTP or None protocol from the Protocol Type list.
5. Check Start synchronizing.
6. Define the duration value Seconds after connection initiation. The duration value is specified in
seconds.
Multi-Core Systems
Running Performance Pack on multi-core systems may require more advanced configurations to account for
core affinity and IRQ behavior. For more information, see sk33250

Performance Pack
Performance Measurement
There are various ways to monitor and measure the performance of a Security Gateway.
TCP State and Benchmarking

Certain testing applications (SmartBits or Chariot) generate invalid TCP sequences. The Security Gateway
TCP state check detects these faulty sequences, and drops the packets. As a result, the benchmark fails.
Since these TCP sequences are invalid, they may affect overall Firewall performance.
To disable this type of TCP state check, perform the following operations in
SmartDashboard:
1. In the IPS tab, select Protections > By Protocol > Network Security > TCP > Sequence Verifier.
2. Select the profile assigned to your gateway and click Edit.
3. In the Action field, select Inactive.
4. Click OK to close the Protections Settings window.
5. Click OK to close the Protections Details window.
6. Click Install Policy to apply the changes.
Non-accelerated traffic analysis

Use the fwaccel stats command to verify the amount of non-accelerated traffic compared to accelerated
traffic.
Use the sim dbg + f2f command to understand the possible reasons for the non-accelerated traffic.
Performance Troubleshooting
Additional CLI commands, such as ethtool, are available to monitor the performance of the gateway. For a
list of these commands and explanation of their usage, see sk33781

Chapter 2
CoreXL Administration
In This Section:
Supported Platforms and Unsupported Features ................................................... 20
Default Configuration .............................................................................................. 21
CoreXL for IPv6....................................................................................................... 21
Configuring IPv4 and IPv6 Firewall Instances ........................................................ 21
Performance Tuning ............................................................................................... 23
Configuring CoreXL ................................................................................................ 29
Command Line Reference ...................................................................................... 29
CoreXL is a performance-enhancing technology for Security Gateways on multi-core processing platforms.

CoreXL enhances Security Gateway performance by enabling the processing cores to concurrently perform
multiple tasks.
CoreXL provides almost linear scalability of performance, according to the number of processing cores on a
single machine. The increase in performance is achieved without requiring any changes to management or
to network topology.
CoreXL joins ClusterXL Load Sharing and SecureXL as part of Check Point's fully complementary family of
traffic acceleration technologies.
On a Security Gateway with CoreXL enabled, the Firewall kernel is replicated multiple times. Each
replicated copy, or instance, runs on one processing core. These instances handle traffic concurrently, and
each instance is a complete and independent inspection kernel. When CoreXL is enabled, all the kernel
instances in the Security Gateway process traffic through the same interfaces and apply the same security
policy.
Supported Platforms and Unsupported Features

CoreXL is supported on:
‚ SecurePlatform
‚ Gaia
‚ IPSO
‚ Crossbeam platforms
Unsupported Features:
CoreXL does not support these Check Point Suite features:
‚ Check Point QoS (Quality of Service)
‚ Route-based VPN
‚ Overlapping NAT
To enable a non-supported feature in the Check Point Suite, disable CoreXL using cpconfig and reboot the
gateway (see Configuring CoreXL (on page 29)).

Default Configuration
When you enable CoreXL, the number of kernel instances is based on the total number of CPU cores.
Number of Cores Number of Kernel Instances
1 1
2 2
4 3
6-20 Number of cores, minus 2
More than 20 Number of cores, minus 4 -- but no more than 30
The default affinity setting for all interfaces is automatic when Performance Pack is installed. See
Processing Core Allocation (on page 23). Traffic from all interfaces is directed to the core running the
Secure Network Distributor (SND).
CoreXL for IPv6

R77 and higher supports multiple cores for IPv6 traffic. For each firewall kernel instance that works with IPv4
traffic, there is a corresponding firewall kernel instance that also works with IPv6 traffic. Both instances run
on the same core.
To check the status of CoreXL on your Security Gateway, run:
fw6 ctl multik stat.
The fw6 ctl multik stat (multi-kernel statistics) command shows IPv6 information for each kernel
instance. The state and processing core number of each instance is displayed, along with:
‚ The number of connections currently running.
‚ The peak number of concurrent connections the instance has used since its inception.
Configuring IPv4 and IPv6 Firewall Instances

After IPv6 support is enabled on the gateway, you can configure the gateway processing cores to run
different combinations of IPv4 and IPv6 firewall kernel instances.
‚ The number of IPv4 instances range from a minimum of two to a number equal to the maximum number
of cores on the gateway.
By default, the number of IPv6 firewall instances is set to two.
‚ The number of IPv6 instances range from a minimum of two to a number equal to the number of IPv4
instances.
The number of IPv6 instances cannot exceed the number of IPv4 instances.
‚ The total number of IPv4 and IPv6 instances cannot exceed: 32.
To configure the number of IPv6 firewall instances:

1. Open a command prompt on the gateway.
2. Run: cpconfig.
The configuration menu shows.
3. Enter option 8: Check Point CoreXL.

Configure Check Point CoreXL...

===========================
CoreXL is currently enabled with 3 firewall instances and 2 IPv6 firewall
instances.
(1) Change the number of firewall instances

(2) Change the number of IPv6 firewall instances
(3) Disable Check Point CoreXL
(4) Exit
The Configuring Check Point CoreXL menu shows how many IPv4 and IPv6 firewall instances are
running on the processing cores.
4. Enter option 2: Change the number of IPv6 firewall instances.
The menu shows how many cores are available on the gateway.
5. Enter the total number of IPv6 firewall instances to run.
You can only select a number from within the range shown.
Note - In a clustered deployment, changing the number of kernel instances should be treated as a
version upgrade.
Example:
A gateway that has four cores and is running three IPv4 instances of the firewall kernel and two IPv6
instances of the firewall kernel can be represented like this:
Core Firewall instances IPv6 Firewall instances
CPU 0
CPU 1 fw4_2
CPU 2 fw4_1 fw6_1
CPU 3 fw4_0 fw6_0
3 instances of IPv4 2 instances of IPv6
‚ The minimum allowed number of IPv4 instances is two and the maximum four
‚ The minimum allowed number of IPv6 instances is two and the maximum is three
To increase the number of IPv6 instances to four, you must first increase the number of IPv4 firewall
instances to the maximum of four:
How many firewall instances would you like to enable (2 to 4)[3] ? 4
CoreXL was enabled successfully with 4 firewall instances.

Important: This change will take effect after reboot.
The gateway now looks like this:
CPU 0 fw4_3
CPU 1 fw4_2
CPU 2 fw4_1 fw6_1
CPU 3 fw4_0 fw6_0

Increase the number of IPv6 instances to four:

How many IPv6 firewall instances would you like to enable (2 to 4)[2] ? 4
CoreXL was enabled successfully with 3 IPv6 firewall instances.

Important: This change will take effect after reboot.
The gateway now looks like this:
CPU 0 fw4_3 fw6_3
CPU 1 fw4_2 fw6_2
CPU 2 fw4_1 fw6_1
CPU 3 fw4_0 fw6_0
Performance Tuning
The following sections are relevant only for SecurePlatform and Gaia.
Processing Core Allocation

The CoreXL software architecture includes the Secure Network Distributor (SND). The SND is responsible
for:
‚ Processing incoming traffic from the network interfaces
‚ Securely accelerating authorized packets (if Performance Pack is running)
‚ Distributing non-accelerated packets among kernel instances.
Traffic entering network interface cards (NICs) is directed to a processing core running the SND. The
association of a particular interface with a processing core is called the interface's affinity with that core. This
affinity causes the interface's traffic to be directed to that core and the SND to run on that core. Setting a
kernel instance or a process to run on a particular core is called the instance's or process's affinity with that
core.
The default affinity setting for all interfaces is Automatic. Automatic affinity means that if Performance Pack
is running, the affinity for each interface is automatically reset every 60 seconds, and balanced between
available cores. If Performance Pack is not running, the default affinities of all interfaces are with one
available core. In both cases, any processing core running a kernel instance, or defined as the affinity for
another process, is considered unavailable and will not be set as the affinity for any interface.
In some cases, which are discussed in the following sections, it may be advisable to change the distribution
of kernel instances, the SND, and other processes, among the processing cores. This is done by changing
the affinities of different NICs (interfaces) and/or processes. However, to ensure CoreXL's efficiency, all
interface traffic must be directed to cores not running kernel instances. Therefore, if you change affinities of
interfaces or other processes, you will need to accordingly set the number of kernel instances and ensure
that the instances run on other processing cores.
Under normal circumstances, it is not recommended for the SND and an instance to share a core.
However, it is necessary for the SND and an instance to share a core when using a machine with exactly
two cores.
Allocating Processing Cores

In certain cases, it may be advisable to change the distribution of kernel instances, the SND, and other
processes, among the processing cores. This section discusses these cases.
Before planning core allocation, make sure you have read the Processing Core Allocation (on page 23).

Adding Processing Cores to the Hardware

Increasing the number of processing cores on the hardware platform does not automatically increase the
number of kernel instances. If the number of kernel instances is not increased, CoreXL does not utilize
some of the processing cores. After upgrading the hardware, increase the number of kernel instances using
cpconfig.
Reinstalling the gateway will change the number of kernel instances if you have upgraded the hardware to
an increased number of processing cores, or if the number of processing cores stays the same but the
number of kernel instances was previously manually changed from the default. Use cpconfig to reconfigure
the number of kernel instances.
In a clustered deployment, changing the number of kernel instances (such as by reinstalling CoreXL) should
be treated as a version upgrade. Follow the instructions in the R77 Installation and Upgrade Guide
See the "Upgrading ClusterXL Deployments" chapter, and perform either a Minimal Effort Upgrade (using
network downtime) or a Zero Downtime Upgrade (no downtime, but active connections may be lost),
substituting the instance number change for the version upgrade in the procedure. A Full Connectivity
Upgrade cannot be performed when changing the number of kernel instances in a clustered environment.
Allocating an Additional Core to the SND

In some cases, the default configuration of instances and the SND will not be optimal. If the SND is slowing
the traffic, and your platform contains enough cores that you can afford to reduce the number of kernel
instances, you may want to allocate an additional core to the SND. This is likely to occur especially if much
of the traffic is of the type accelerated by Performance Pack; in a ClusterXL Load Sharing deployment; or if
IPS features are disabled. In any of these cases, the task load of the SND may be disproportionate to that of
the kernel instances.
To check if the SND is slowing down the traffic:

1. Identify the processing core to which the interfaces are directing traffic using fw ctl affinity -l -r.
2. Under heavy traffic conditions, run the top command on the CoreXL gateway and check the values for
the different cores under the 'idle' column.
It is recommended to allocate an additional core to the SND only if all of the following conditions are met:
‚ Your platform has at least eight processing cores.
‚ The 'idle' value for the core currently running the SND is in the 0%-5% range.
‚ The sum of the 'idle' values for the cores running kernel instances is significantly higher than 100%.
If any of the above conditions are not met, the default configuration of one processing core allocated to the
SND is sufficient, and no further configuration is necessary.
Allocating an additional processing core to the SND requires performing the following two stages in the
order that they appear:
1. Reduce the number of kernel instances using cpconfig.
2. Set interface affinities to the remaining cores, as detailed below.
3. Reboot to implement the new configuration.
Setting Interface Affinities

Check which cores are running the kernel instances. See also Allocating Processing Cores (on page 23).
Allocate the remaining cores to the SND by setting interface affinities to the cores. The correct method of
defining interface affinities depends on whether or not Performance Pack is running, as described in the
following sections.
‚ When Performance Pack is Running
If Performance Pack is running, interface affinities are handled by using the Performance Pack sim
affinity command.
The default sim affinity setting is Automatic. In the Performance Pack Automatic mode, interface
affinities are automatically distributed among cores that are not running kernel instances and that are not
set as the affinity for any other process.
In most cases, you do not need to change the sim affinity setting.

‚ Setting Interface Affinities when Performance Pack is not Running

If Performance Pack is not running, interface affinities are loaded at boot from a configuration text file
called fwaffinity.conf, located under: $FWDIR/conf . In the text file, lines beginning with the letter i
define interface affinities.
If Performance Pack is running, interface affinities are defined by sim affinity settings, and lines
beginning with i in fwaffinity.conf are ignored.
If you are allocating only one processing core to the SND, it is best to have that core selected
automatically by leaving the default interface affinity set to automatic, and having no explicit core
affinities for any interfaces. To do this, make sure fwaffinity.conf contains the following line:
i default auto
In addition, make sure that fwaffinity.conf contains no other lines beginning with i, so that no explicit
interface affinities are defined. All interface traffic will be directed to the remaining core.
If you are allocating two processing cores to the SND, you need to explicitly set interface affinities to the
two remaining cores. If you have multiple interfaces, you need to decide which interfaces to set for each
of the two cores. Try to achieve a balance of expected traffic between the cores (you can later check the
balance by using the top command).
To explicitly set interface affinities, when Performance Pack is not running:

1. Set the affinity for each interface by editing fwaffinity.conf. The file should contain one line beginning
with i for each interface. Each of these lines should follow the following syntax:
i <interfacename> <cpuid>
where <interfacename> is the interface name, and <cpuid> is the number of the processing core to be
set as the affinity of that interface.
For example, if you want the traffic from eth0 and eth1 to go to core #0, and the traffic from eth2 to go
to core #1, create the following lines in fwaffinity.conf:
i eth0 0
i eth1 0
i eth2 1
Alternatively, you can choose to explicitly define interface affinities for only one processing core, and
define the other core as the default affinity for the remaining interfaces, by using the word default for
<interfacename>.
In the case described in the previous example, the lines in fwaffinity.conf would be:
i eth2 1
i default 0
2. Run $FWDIR/scripts/fwaffinity_apply for the fwaffinity.conf settings to take effect.
The affinity of virtual interfaces can be set using their physical interface(s).
Allocating a Core for Heavy Logging

If the gateway is performing heavy logging, it may be advisable to allocate a processing core to the fwd
daemon, which performs the logging. Like adding a core for the SND, this too will reduce the number of
cores available for kernel instances.
To allocate a processing core to the fwd daemon, you need to do two things:
2. Set the fwd daemon affinity, as detailed below.
Setting the fwd Daemon Affinity

Check which processing cores are running the kernel instances and which cores are handling interface
traffic using fw ctl affinity -l -r. Allocate the remaining core to the fwd daemon by setting the fwd daemon
affinity to that core.
Note: Avoiding the processing core or cores that are running the SND is important only if these cores are
explicitly defined as affinities of interfaces. If interface affinities are set to Automatic, any core that is not
running a kernel instance can be used for the fwd daemon, and interface traffic will be automatically diverted
to other cores.

Affinities for Check Point daemons (such as the fwd daemon), if set, are loaded at boot from the
fwaffinity.conf configuration text file located at: $FWDIR/conf . Edit the file by adding the following line:
n fwd <cpuid>
where <cpuid> is the number of the processing core to be set as the affinity of the fwd daemon. For
example, to set core #2 as the affinity of the fwd daemon, add to the file:
n fwd 2
Reboot for the fwaffinity.conf settings to take effect.
Performance Tuning
The following sections are relevant only for SecurePlatform and Gaia.
Processing Core Allocation

The CoreXL software architecture includes the Secure Network Distributor (SND). The SND is responsible
for:
‚ Processing incoming traffic from the network interfaces
‚ Securely accelerating authorized packets (if Performance Pack is running)
‚ Distributing non-accelerated packets among kernel instances.
Traffic entering network interface cards (NICs) is directed to a processing core running the SND. The
association of a particular interface with a processing core is called the interface's affinity with that core. This
affinity causes the interface's traffic to be directed to that core and the SND to run on that core. Setting a
kernel instance or a process to run on a particular core is called the instance's or process's affinity with that
core.
The default affinity setting for all interfaces is Automatic. Automatic affinity means that if Performance Pack
is running, the affinity for each interface is automatically reset every 60 seconds, and balanced between
available cores. If Performance Pack is not running, the default affinities of all interfaces are with one
available core. In both cases, any processing core running a kernel instance, or defined as the affinity for
another process, is considered unavailable and will not be set as the affinity for any interface.
In some cases, which are discussed in the following sections, it may be advisable to change the distribution
of kernel instances, the SND, and other processes, among the processing cores. This is done by changing
the affinities of different NICs (interfaces) and/or processes. However, to ensure CoreXL's efficiency, all
interface traffic must be directed to cores not running kernel instances. Therefore, if you change affinities of
interfaces or other processes, you will need to accordingly set the number of kernel instances and ensure
that the instances run on other processing cores.
Under normal circumstances, it is not recommended for the SND and an instance to share a core.
However, it is necessary for the SND and an instance to share a core when using a machine with exactly
two cores.
Allocating Processing Cores

In certain cases, it may be advisable to change the distribution of kernel instances, the SND, and other
processes, among the processing cores. This section discusses these cases.
Before planning core allocation, make sure you have read the Processing Core Allocation (on page 23).
Adding Processing Cores to the Hardware

Increasing the number of processing cores on the hardware platform does not automatically increase the
number of kernel instances. If the number of kernel instances is not increased, CoreXL does not utilize
some of the processing cores. After upgrading the hardware, increase the number of kernel instances using
cpconfig.
Reinstalling the gateway will change the number of kernel instances if you have upgraded the hardware to
an increased number of processing cores, or if the number of processing cores stays the same but the

number of kernel instances was previously manually changed from the default. Use cpconfig to reconfigure
the number of kernel instances.
In a clustered deployment, changing the number of kernel instances (such as by reinstalling CoreXL) should
be treated as a version upgrade. Follow the instructions in the R77 Installation and Upgrade Guide
See the "Upgrading ClusterXL Deployments" chapter, and perform either a Minimal Effort Upgrade (using
network downtime) or a Zero Downtime Upgrade (no downtime, but active connections may be lost),
substituting the instance number change for the version upgrade in the procedure. A Full Connectivity
Upgrade cannot be performed when changing the number of kernel instances in a clustered environment.
Allocating an Additional Core to the SND

In some cases, the default configuration of instances and the SND will not be optimal. If the SND is slowing
the traffic, and your platform contains enough cores that you can afford to reduce the number of kernel
instances, you may want to allocate an additional core to the SND. This is likely to occur especially if much
of the traffic is of the type accelerated by Performance Pack; in a ClusterXL Load Sharing deployment; or if
IPS features are disabled. In any of these cases, the task load of the SND may be disproportionate to that of
the kernel instances.
To check if the SND is slowing down the traffic:

1. Identify the processing core to which the interfaces are directing traffic using fw ctl affinity -l -r.
2. Under heavy traffic conditions, run the top command on the CoreXL gateway and check the values for
the different cores under the 'idle' column.
It is recommended to allocate an additional core to the SND only if all of the following conditions are met:
‚ Your platform has at least eight processing cores.
‚ The 'idle' value for the core currently running the SND is in the 0%-5% range.
‚ The sum of the 'idle' values for the cores running kernel instances is significantly higher than 100%.
If any of the above conditions are not met, the default configuration of one processing core allocated to the
SND is sufficient, and no further configuration is necessary.
Allocating an additional processing core to the SND requires performing the following two stages in the
order that they appear:
2. Set interface affinities to the remaining cores, as detailed below.
3. Reboot to implement the new configuration.
Setting Interface Affinities

Check which cores are running the kernel instances. See also Allocating Processing Cores (on page 23).
Allocate the remaining cores to the SND by setting interface affinities to the cores. The correct method of
defining interface affinities depends on whether or not Performance Pack is running, as described in the
following sections.
‚ When Performance Pack is Running
If Performance Pack is running, interface affinities are handled by using the Performance Pack sim
affinity command.
The default sim affinity setting is Automatic. In the Performance Pack Automatic mode, interface
affinities are automatically distributed among cores that are not running kernel instances and that are not
set as the affinity for any other process.
In most cases, you do not need to change the sim affinity setting.
‚ Setting Interface Affinities when Performance Pack is not Running
If Performance Pack is not running, interface affinities are loaded at boot from a configuration text file
called fwaffinity.conf, located under: $FWDIR/conf . In the text file, lines beginning with the letter i
define interface affinities.
If Performance Pack is running, interface affinities are defined by sim affinity settings, and lines
beginning with i in fwaffinity.conf are ignored.

If you are allocating only one processing core to the SND, it is best to have that core selected
automatically by leaving the default interface affinity set to automatic, and having no explicit core
affinities for any interfaces. To do this, make sure fwaffinity.conf contains the following line:
i default auto
In addition, make sure that fwaffinity.conf contains no other lines beginning with i, so that no explicit
interface affinities are defined. All interface traffic will be directed to the remaining core.
If you are allocating two processing cores to the SND, you need to explicitly set interface affinities to the
two remaining cores. If you have multiple interfaces, you need to decide which interfaces to set for each
of the two cores. Try to achieve a balance of expected traffic between the cores (you can later check the
balance by using the top command).
To explicitly set interface affinities, when Performance Pack is not running:

1. Set the affinity for each interface by editing fwaffinity.conf. The file should contain one line beginning
with i for each interface. Each of these lines should follow the following syntax:
i <interfacename> <cpuid>
where <interfacename> is the interface name, and <cpuid> is the number of the processing core to be
set as the affinity of that interface.
For example, if you want the traffic from eth0 and eth1 to go to core #0, and the traffic from eth2 to go
to core #1, create the following lines in fwaffinity.conf:
i eth0 0
i eth1 0
i eth2 1
Alternatively, you can choose to explicitly define interface affinities for only one processing core, and
define the other core as the default affinity for the remaining interfaces, by using the word default for
<interfacename>.
In the case described in the previous example, the lines in fwaffinity.conf would be:
i eth2 1
i default 0
2. Run $FWDIR/scripts/fwaffinity_apply for the fwaffinity.conf settings to take effect.
The affinity of virtual interfaces can be set using their physical interface(s).
Allocating a Core for Heavy Logging

If the gateway is performing heavy logging, it may be advisable to allocate a processing core to the fwd
daemon, which performs the logging. Like adding a core for the SND, this too will reduce the number of
cores available for kernel instances.
To allocate a processing core to the fwd daemon, you need to do two things:
2. Set the fwd daemon affinity, as detailed below.
Setting the fwd Daemon Affinity

Check which processing cores are running the kernel instances and which cores are handling interface
traffic using fw ctl affinity -l -r. Allocate the remaining core to the fwd daemon by setting the fwd daemon
affinity to that core.
Note: Avoiding the processing core or cores that are running the SND is important only if these cores are
explicitly defined as affinities of interfaces. If interface affinities are set to Automatic, any core that is not
running a kernel instance can be used for the fwd daemon, and interface traffic will be automatically diverted
to other cores.
Affinities for Check Point daemons (such as the fwd daemon), if set, are loaded at boot from the
fwaffinity.conf configuration text file located at: $FWDIR/conf . Edit the file by adding the following line:
n fwd <cpuid>
where <cpuid> is the number of the processing core to be set as the affinity of the fwd daemon. For
example, to set core #2 as the affinity of the fwd daemon, add to the file:

n fwd 2
Reboot for the fwaffinity.conf settings to take effect.
Configuring CoreXL
To enable/disable CoreXL:
1. Log in to the Security Gateway.
2. Run cpconfig
3. Select Configure Check Point CoreXL.
4. Enable or disable CoreXL.
5. Reboot the Security Gateway.
To configure the number of instances:

1. Run cpconfig
2. Select Configure Check Point CoreXL.
3. If CoreXL is enabled, enter the number of firewall instances.
If CoreXL is disabled, enable CoreXL and then set the number of firewall instances.
Reboot the gateway.
Note - In a clustered deployment, changing the number of kernel instances should be treated
as a version upgrade.
Command Line Reference

Affinity Settings
Affinity settings controlled by the fwaffinity_apply script file, which executes automatically at boot. When you
make a change to affinity settings, the settings will not take effect until you either reboot or manually execute
the fwaffinity_apply script.
fwaffinity_apply executes affinity definitions according to the information in the fwaffinity.conf text file. To
change affinity settings, edit the text file.
Note - If Performance Pack is running, interface affinities are only defined by the Performance
Pack sim affinity command. The fwaffinity.conf interface affinity settings are ignored.
fwaffinity.conf
fwaffinity.conf is located in the $FWDIR/conf directory.
Syntax
Each line in the text file uses the same format: <type> <id> <cpu>
Data Values Description
<type> i interface
n Check Point daemon
k kernel instance

Data Values Description
<id> interface name if <type> = i
daemon name if <type> = n
instance number if <type> = k
default interfaces that are not specified in another line
<cpuid> <number> number(s) of processing core(s) to be set as the affinity
all all processing cores are available to the interface traffic, daemon or
kernel instance
ignore no specified affinity (useful for excluding an interface from a default

setting)
auto Automatic mode See also Processing Core Allocation (on page 23).
Note - Interfaces that share an IRQ cannot have different cores as their affinities, including
when one interface is included in the default affinity setting. Either set both interfaces to the
same affinity, or use ignore for one of them. To view the IRQs of all interfaces, run: fw ctl
affinity -l -v -a .
fwaffinty_apply
fwaffinity_apply is located in the $FWDIR/scripts directory. Use the following syntax to execute the
command: $FWDIR/scripts/fwaffinity_apply <option>
where <option> is one of the following parameters:
Parameter Description
-q Quiet mode - print only error messages.
-t <type> Only apply affinity for the specified type.
-f Sets interface affinity even if automatic affinity is active.
fw ctl affinity
The fw ctl affinity command controls affinity settings. However, fw ctl affinity settings will not persist through
a restart of the Security Gateway.
To set affinities, execute fw ctl affinity -s.
To list existing affinities, execute fw ctl affinity -l.
fw ctl affinity -s
Use this command to set affinities.
fw ctl affinity -s settings are not persistent through a restart of the Security Gateway. If you want the settings
to be persistent, either use sim affinity or edit the fwaffinity.conf configuration file.
To set interface affinities, you should use fw ctl affinity only if Performance Pack is not running. If
Performance Pack is running, you should set affinities by using the Performance Pack sim affinity command.
These settings will be persistent. If the Performance Pack sim affinity is set to Automatic mode (even if

Performance Pack was subsequently disabled), you will not be able to set interface affinities by using fw ctl
affinity -s.
Syntax
fw ctl affinity -s <proc_selection> <cpuid>
<proc_selection> is one of the following parameters:
-p <pid> Sets affinity for a particular process, where <pid> is the process ID#.
-n <cpdname> Sets affinity for a Check Point daemon, where <cpdname> is the Check
Point daemon name (for example: fwd).
-k <instance> Sets affinity for a kernel instance, where <instance> is the instance's
number.
-i <interfacename> Sets affinity for an interface, where <interfacename> is the interface

name (for example: eth0).
<cpuid> should be a processing core number or a list of processing core numbers. To have no affinity to
any specific processing core, <cpuid> should be: all.
Note - Setting an Interface Affinity will set the affinities of all interfaces sharing the same IRQ to
the same processing core.
To view the IRQs of all interfaces, run: fw ctl affinity -l -v -a
Example
To set kernel instance #3 to run on processing core #5, run:
fw ctl affinity -s -k 3 5
fw ctl affinity -l
Use this command to list existing affinities. For an explanation of kernel, daemon and interface affinities, see
CoreXL Administration (on page 20).
Syntax
fw ctl affinity -l [<proc_selection>] [<listtype>]
If <proc_selection> is omitted, fw ctl affinity -l lists affinities of all Check Point daemons,
kernel instances and interfaces. Otherwise, <proc_selection> is one of the following parameters:
-p <pid> Displays the affinity of a particular process, where <pid> is the process ID#.
-n <cpdname> Displays the affinity of a Check Point daemon, where <cpdname> is the
Check Point daemon name (for example: fwd).
-k <instance> Displays the affinity of a kernel instance, where <instance> is the instance's
number.
-i <interfacename> Displays the affinity of an interface, where <interfacename> is the

interface name (for example: eth0).

If <listtype> is omitted, fw ctl affinity -l lists items with specific affinities, and their affinities.
Otherwise, <listtype> is one or more of the following parameters:
-a All: includes items without specific affinities.
-r Reverse: lists each processing core and the items that have it as their affinity.
-v Verbose: list includes additional information.
Example
To list complete affinity information for all Check Point daemons, kernel instances and interfaces, including
items without specific affinities, and with additional information, run:
fw ctl affinity -l -a -v
fw ctl multik stat

The fw ctl multik stat and fw6 ctl multik stat (multi-kernel statistics) commands show
information for each kernel instance. The state and processing core number of each instance is displayed,
along with:
‚ The number of connections currently being handled.
‚ The peak number of concurrent connections the instance has handled since its inception.

Chapter 3
Multi-Queue
In This Section:
Introduction to Multiple Traffic Queues ................................................................... 33
Basic Multi-Queue Configuration ............................................................................ 36
Multi-Queue Administration..................................................................................... 37
Advanced Multi-Queue settings .............................................................................. 38
Special Scenarios and Configurations .................................................................... 40
Troubleshooting ...................................................................................................... 41
This section covers Multi-Queue.
Introduction to Multiple Traffic Queues

By default, each network interface has one traffic queue handled by one CPU. You cannot use more CPUs
for acceleration than the number of interfaces handling traffic. Multi-Queue lets you configure more than one
traffic queue for each network interface. For each interface, more than one CPU is used for acceleration.
Multi-Queue Requirements and Limitations

‚ Multi-Queue is not supported on single core computers.
‚ Network interfaces must support Multi-Queue
‚ The number of queues is limited by the number of CPUs and the type of interface driver:
Driver type Maximum number of rx queues
Igb 4
Ixgbe 16
Deciding if Multi-Queue is needed

This section will help you decide if you can benefit from configuring Multi-Queue. We recommend that you
do these steps before configuring Multi-Queue:
‚ Make sure that SecureXL is enabled
‚ Examine the CPU roles allocation
‚ Examine CPU Utilization
‚ Decide if more CPUs can be allocated to the SND
‚ Make sure that network interfaces support Multi-Queue
Making sure that SecureXL is enabled

1. On the Security Gateway, run: fwaccel stat
2. Examine the Accelerator Status value:

Multi-Queue
[Expert@gw-30123d:0]# fwaccel stat

Accelerator Status : on
Accept Templates : enabled
Drop Templates : disabled
NAT Templates : disabled by user
Accelerator Features : Accounting, NAT, Cryptography, Routing,

HasClock, Templates, Synchronous, IdleDetection,
Sequencing, TcpStateDetect, AutoExpire,
DelayedNotif, TcpStateDetectV2, CPLS, WireMode,
DropTemplates, NatTemplates, Streaming,
MultiFW, AntiSpoofing, DoS Defender, ViolationStats,
Nac, AsychronicNotif, ERDOS
Cryptography Features : Tunnel, UDPEncapsulation, MD5, SHA1, NULL,
3DES, DES, CAST, CAST-40, AES-128, AES-256,
ESP, LinkSelection, DynamicVPN, NatTraversal,
EncRouting, AES-XCBC, SHA256
SecureXL is enabled if the value of this field is: on.
Note - Multi-Queue is relevant only if SecureXL is enabled.
Examining the CPU roles allocation

To see the CPU roles allocation, run: fw ctl affinity –l
This command shows the CPU affinity of the interfaces, which assigns SND CPUs. It also shows the
CoreXL firewall instances CPU affinity. For example, if you run the command on a Security Gateway:
[Expert@gw-30123d:0]# fw ctl affinity -l
Mgmt: CPU 0
eth1-05: CPU 0
eth1-06: CPU 1
fw_0: CPU 5
fw_1: CPU 4
fw_2: CPU 3
fw_3: CPU 2
In this example:
‚ The SND is running on CPU 0 and CPU1
‚ CoreXL firewall instances are running on CPUs 2-5
If you run the command on a VSX gateway:
Mgmt: CPU 0
eth1-05: CPU 0
eth1-06: CPU 1
VS_0 fwk: CPU 2 3 4 5
VS_1 fwk: CPU 2 3 4 5
In this example:
‚ The SND is running on CPU 0-1
‚ CoreXL firewall instances (part of fwk processes) of all the Virtual System are running on CPUs 2-5.
Examining CPU Utilization

1. On the Security Gateway, run: top.
2. Press 1 to toggle the SMP view.

Multi-Queue
This shows the usage and idle percentage for each CPU. For example:
In this example:
‚ SND CPUs (CPU0 and CPU1) are approximately 30% idle
‚ CoreXL firewall instances CPUs are approximately 70% idle
Deciding if more CPUs can be allocated to the SND

If you have more network interfaces handling traffic than CPUs assigned to the SND , you can allocate more
CPUs for SND. For example, if you have the following network interfaces:
‚ eth1-04 – connected to an internal network
‚ eth1-05 – connected to an internal network
‚ eth1-06 – connected to the DMZ
‚ eth1-07 – connected to the external network
And running fw ctl affinity -l shows this IRQ affinity:
Mgmt: CPU 0
eth1-04: CPU 1
eth1-05: CPU 0
eth1-06: CPU 1
eth1-07: CPU 0
fw_0: CPU 5
fw_1: CPU 4
fw_2: CPU 3
fw_3: CPU 2
You can use the Sim affinity utility to change an interface's IRQ affinity to use more CPUs for the SND. You
can do this:
‚ Even before the Multi-Queue feature is activated
‚ If you have more network interfaces handling traffic than CPUs assigned to the SND
Making sure that the network interfaces support Multi-Queue

Multi-Queue is supported only on network cards that use igb (1Gb) or ixgbe (10Gb) drivers. Before
upgrading these drivers, make sure that the latest version supports Multi-Queue.

Multi-Queue
Gateway type Expansion Card Model
Security Appliance Multi-Queue is supported on these expansion cards for 4000, 12000, and 21000
appliances:
‚ CPAC-ACC-4-1C
‚ CPAC-ACC-4-1F
‚ CPAC-ACC-8-1C
‚ CPAC-ACC-2-10F
‚ CPAC-ACC-4-10F
IP appliance The XMC 1Gb card is supported on:
‚ IP1280
‚ IP2450
Open server Network cards that use igb (1Gb) or ixgbe (10Gb) drivers
‚ To view which driver an interface is using, run: ethtool -i <interface name>.

‚ When installing a new interface that uses the igb or ixgbe driver, run: cpmq reconfigure and reboot.
Recommendation
We recommend configuring Multi-Queue when:
‚ CPU load for SND is high (idle is less than 20%) and
‚ CPU load for CoreXL firewall instances are low (idle is greater than 50%)
‚ You cannot assign more CPUs to the SND by changing interface IRQ affinity
Basic Multi-Queue Configuration

The cpmq utility is used to view or change the current Multi-Queue configuration.
Configuring Multi-Queue
The cpmq set command lets you to configure Multi-Queue on supported interfaces.
To configure Multi-Queue:
‚ On the gateway, run: cpmq set
This command:
‚ Shows all supported interfaces that are active
‚ Lets you change the Multi-Queue configuration for each interface.
Network interfaces that are down are not in the output.
Note -
̇ Multi-Queue lets you configure a maximum of five interfaces
̇ You must reboot the gateway after changing the Multi-Queue configuration
Querying the current Multi-Queue configuration

The cpmq get command shows the Multi-Queue status of supported interfaces.
To see the Multi-Queue configuration:

Run: cpmq get [-a]
The -a option shows the Multi-Queue configuration for all supported interfaces (both active and inactive).
For example:

Multi-Queue
[Expert@gw-30123d:0]# cpmq get -a
Active igb interfaces:

eth1-05 [On]
eth1-06 [Off]
eth1-01 [Off]
eth1-03 [Off]
eth1-04 [On]
Non active igb interfaces:

eth1-02 [Off]
Status messages
Status Meaning
On Multi-Queue is enabled on the interface.
Off Multi-Queue is disabled on the interface.
Pending On Multi-Queue currently disabled. Multi-Queue will be enabled on this interface only after
rebooting the gateway.
Note: Pending on can also indicate bad configuration or system errors. For more, see
the section on troubleshooting (on page 41).
Pending Off Multi-Queue enabled. Multi-Queue will be disabled on this interface only after rebooting
the gateway.
In this example:
‚ Two interfaces are up with Multi-Queue enabled
(eth1-05, eth1-04)
‚ Three interfaces are up with Multi-Queue disabled
(eth1-06, eth1-01, eth1-03)
‚ One interface that supports Multi-Queue is down
(eth1-02)
Running the command without the -a option shows the active interfaces only.
Multi-Queue Administration
There are two main roles for CPUs applicable to SecureXL and CoreXL:
‚ SecureXL and CoreXL dispatcher CPU (the SND - Secure Network Distributor)
You can manually configure this using the sim affinity -s command.
‚ CoreXL firewall instance CPU
You can manually configure this using the fw ctl affinity command.
For best performance, the same CPU should not work in both roles. During installation, a default CPU role
configuration is set. For example, on a twelve core computer, the two CPUs with the lowest CPU ID are set
as SNDs and the ten CPUs with the highest CPU IDs are set as CoreXL firewall instances.
Without Multi-Queue, the number of CPUs allocated to the SND is limited by the number of network
interfaces handling the traffic. Since each interface has one traffic queue, each queue can be handled by
only one CPU at a time. This means that the SND can use only one CPU at a time per network interface.
When most of the traffic is accelerated, the CPU load for SND can be very high while the CPU load for
CoreXL firewall instances can be very low. This is an inefficient utilization of CPU capacity.
Multi-Queue lets you configure more than one traffic queue for each supported network interface, so that
more than one SND CPU can handle the traffic of a single network interface at a time. This balances the
load efficiently between SND CPUs and CoreXL firewall instances CPUs.
Multi-Queue
Advanced Multi-Queue settings

Advanced Multi-Queue settings include:
‚ Controlling the number of queues
‚ IRQ Affinity
‚ Viewing CPU Utilization
Controlling the number of queues

Controlling the number of queues depends on the driver type:
Driver Queues Recommended

type number
of rx queues
ixgbe ‚ When configuring Multi-Queue for an ixgbe interface, an RxTx 16
queue is created per CPU. You can control the number of active rx
queues using rx_num.
‚ All tx queues are active.
igb When configuring Multi-Queue for an igb interface, the number of tx and 4
rx queues is calculated by the number of active rx queues.
‚ By default on a Security Gateway, the number of active rx queues is calculated by:

active rx queues = Number of CPUs – number of CoreXL firewall instances
‚ By default on a VSX gateway, the number of active rx queues is calculated by:
active rx queues = the lowest CPU ID that an fwk process is assigned to
To control the number of active rx queues:

Run: cpmq set rx_num <igb/ixgbe> <number of active rx queues>
This command overrides the default value.
To view the number of active rx queues:

Run: cpmq get rx_num <igb/ixgbe>
To return to the recommended number of rx queues:

On a Security Gateway, the number of active queues changes automatically when you change the number
of CoreXL firewall instances (using cpconfig). This number of active queues does not change if you
configure the number of rx queues manually.
Run: cpmq set rx_num <igb/ixgbe> default
IRQ Affinity
The IRQ affinity of the queues is set automatically when the operating system boots, as shown (rx_num set
to 3):
rxtx-0 -> CPU 0
rxtx-1 -> CPU 1
rxtx-2 -> CPU 2
and so on. This is also true in cases where rx and tx queues are assigned with a separated IRQ:
rx-0 -> CPU 0
tx-0 -> CPU 0
rx-1 -> CPU 1
tx-1 -> CPU 1

Multi-Queue
and so on.
‚ You cannot use the sim affinity or the fw ctl affinity commands to change and query the
IRQ affinity for Multi-Queue interfaces.
‚ You can reset the affinity of Multi-Queue IRQs by running: cpmq set affinity
‚ You can view the affinity of Multi-Queue IRQs by running: cpmq get -v
Important - Do not change the IRQ affinity of queues manually. Changing the IRQ affinity of the
queues manually can affect performance.
Viewing CPU Utilization

1. Find the CPUs assigned to Multi-Queue IRQs by running: cpmq get -v. For example:
[Expert@gw-30123d:0]# cpmq get -v
Active igb interfaces:

eth1-05 [On]
eth1-06 [Off]
eth1-01 [Off]
eth1-03 [Off]
eth1-04 [On]
multi-queue affinity for igb interfaces:
eth1-05:
irq | cpu | queue

-----------------------------------------------------
178 0 TxRx-0
186 1 TxRx-1
eth1-04:
irq | cpu | queue

-----------------------------------------------------
123 0 TxRx-0
131 1 TxRx-1
In this example:
‚ Multi-Queue is enabled on two igb interfaces (eth1-05 and eth1-04)
‚ The number of active rx queues is configured to 2 (for igb, the number of queues is calculated by the
number of active rx queues).
‚ The IRQs for both interfaces are assigned to CPUs 0-1.
2. Run: top
3. Press 1 to toggle to the SMP view.

Multi-Queue
In the above example, CPU utilization of Multi-Queue CPUs is approximately 50%, as CPU0 and CPU1
are handling the queues (as shown in step 1).
Adding more Interfaces

Due to IRQ limitations, you can configure a maximum of five interfaces with Multi-Queue.
To add more interfaces, run: cpmq set -f
Special Scenarios and Configurations

‚ In Security Gateway mode: Changing the number of CoreXL firewall instances when Multi-Queue is
enabled on some or all interfaces
For best performance, the default number of active rx queues is calculated by:
Number of active rx queues = number of CPUs – number of CoreXL firewall instances
This configuration is set automatically when configuring Multi-Queue. When changing the number of
instances, the number of active rx queues will change automatically if it was not set manually.
‚ In VSX mode: changing the number of CPUs that the fwk processes are assigned to
‚ The default number of active rx queues is calculated by:
Number of active rx queues = the lowest CPU ID that an fwk process is assigned to
For example:
Mgmt: CPU 0
eth1-05: CPU 0
eth1-06: CPU 1
VS_0 fwk: CPU 2 3 4 5
VS_1 fwk: CPU 2 3 4 5
In this example
‚ The number of active rx queues is set to 2.
‚ This configuration is set automatically when configuring Multi-Queue.
‚ It will not automatically update when changing the affinity of the Virtual System. When changing the
affinity of the Virtual System, make sure to follow the instructions in Advanced Multi-Queue settings
(on page 38).
The effects of changing the status of a Multi-Queue enabled interface

‚ Changing the status to DOWN
The Multi-Queue configuration is saved when you change the status of an interface to down.
Since the number of interfaces with Multi-Queue enabled is limited to five, you may need to disable
Multi-Queue on an interface after changing its status to down to enable Multi-Queue on other interfaces.
‚ To disable Multi-Queue on non-active interfaces:
a) Activate an interface.
b) Disable the Multi-Queue using the cpmq set command.
c) Deactivate the interface.
‚ Changing the status to UP
You must reset the IRQ affinity for Multi-Queue interfaces if, in this order, you:
‚ Enabled Multi-Queue on the interface
‚ Changed the status of the interface to down
‚ Rebooted the gateway
‚ Changed the interface status to up.
This problem does not occur if you are running automatic sim affinity (sim affinity -a). Automatic
sim affinity runs by default, and has to be manually canceled using the sim affinity -s command.
Multi-Queue
To set the static affinity of Multi-Queue interfaces again, run: cpmq set affinity.
Adding a network interface

‚ When adding a network interface card to a gateway that uses igb or ixgbe drivers, the Multi-Queue
configuration can change due to interface indexing. If you add a network interface card to a gateway that
uses igb or ixgbe drivers make sure to run Multi-Queue configuration again or run: cpmq
reconfigure.
‚ If a reconfiguration change is required, you will be prompted to reboot the computer.
Changing the affinity of CoreXL firewall instances

‚ For best performance, we recommend that you do not assign both SND and a CoreXL firewall instance
to the same CPU.
‚ When changing the affinity of the CoreXL firewall instances to a CPU assigned with one of the Multi-
Queue queues, we recommend that you reconfigure the number of active rx queues following this rule:
Active rx queues = the lowest CPU number that a CoreXL firewall instance is assigned to
‚ You can configure the number of active rx queues by running:
cpmq set rx_num <igb/ixgbe> <value/default>
Troubleshooting
‚ After reboot, the wrong interfaces are configured for Multi-Queue
This can happen after changing the physical interfaces on the gateway. To solve this issue:
a) Run: cpmq reconfigure
b) Reboot.
Or configure Multi-Queue again.
‚ After configuring Multi-Queue and rebooting the gateway, some of the configured interfaces are
shown as down. These interfaces were up before the gateway reboot. The cpmq get –a
command shows the interface status as Pending on.
This can happen when not enough IRQs are available on the gateway. To resolve this issue do one of
these:
‚ Disable some of the interfaces configured for Multi-Queue
‚ Manually reduce the number of active rx queues (rx_num) using the cpmq set rx_num command,
and reboot the gateway
‚ When changing the status of interfaces, all the interface IRQs are assigned to CPU 0 or to all of
the CPUs
This can happen when an interface status is changed to UP after the automatic affinity procedure runs
(the affinity procedure runs automatically during boot).
To solve this issue, run: cpmq set affinity
This problem does not occur if you are running automatic sim affinity (sim affinity -s). Automatic
sim affinity runs by default, and has to be manually canceled using the sim affinity -s command.
‚ In VSX mode, an fwk process runs on the same CPU as some of the interface queues
This can happen when the affinity of the Virtual System was manually changed but Multi-Queue was not
reconfigured accordingly.
To solve this issue, configure the number of active rx queues manually or run: cpmq reconfigure and
reboot.
‚ In Security Gateway mode – after changing the number of instances Multi-Queue is disabled on
all interfaces
When changing the number of CoreXL firewall instances, the number of active rx queues automatically
changes according to this rule (if not configured manually):
Active rx queues = Number of CPUs – number of CoreXL firewall instances

Multi-Queue
If the number of instances is equal to the number of CPUs, or if the difference between the number of
CPUs and the number of CoreXL firewall instances is 1, Multi-Queue will be disabled. To solve this
issue, configure the number of active rx queues manually by running:
cpmq set rx_num <igb/ixgbe> <value>

Installing on Installed SecurePlatform Gateway
with HFA • 9
Index Installing on SecurePlatform Gateway • 9

Introduction to Multiple Traffic Queues • 33
Introduction to Performance Pack • 8
IPv4 • 7
A IPv6 • 7
Adding more Interfaces • 40 IRQ Affinity • 7
Adding Processing Cores to the Hardware • 24,
26
M
Advanced Multi-Queue settings • 38 Multi-Core Systems • 18
Affinity • 7 Multi-queue • 7
Affinity Settings • 29 Multi-Queue • 33
Allocating a Core for Heavy Logging • 25, 28 Multi-Queue Administration • 37
Allocating an Additional Core to the SND • 24, Multi-Queue Requirements and Limitations • 33
27
Allocating Processing Cores • 23, 26 N
B Network Interface Cards • 9
Non-accelerated traffic analysis • 19
Basic Multi-Queue Configuration • 36
BIOS Settings • 9 P
C Performance Measurement • 19
Performance Pack • 8
Command Line • 10 Performance Troubleshooting • 19
Command Line Reference • 29 Performance Tuning • 23, 26
Configuring CoreXL • 29 Performance Tuning and Measurement • 16
Configuring IPv4 and IPv6 Firewall Instances • Preparing the Performance Pack • 9
21 proc entries • 16
Connection Templates • 17 Processing Core Allocation • 23, 26
CoreXL • 7
CoreXL Administration • 20 R
CoreXL for IPv6 • 21 Restrictions • 17
cpconfig • 15 Rx Queue • 7
D S
Deciding if Multi-Queue is needed • 33 SecureXL NAT templates • 17
Default Configuration • 21 SecureXL Templates • 16
Delayed Notification • 17 Setting Interface Affinities • 24, 27
Delayed Synchronization • 18 Setting the fwd Daemon Affinity • 25, 28
E Setting the Maximum Concurrent Connections •
16
Example • 31, 32 sim affinity • 15
fwaccel6 stat • 12 SND • 7
fwaccel6 stats • 13 Special Scenarios and Configurations • 40
fwaccel6 templates • 12 Supported Features • 8
Supported Platforms and Unsupported Features
F • 20
Firewall Instance • 7 Syntax • 29, 31
fw ctl affinity • 30
fw ctl affinity -l • 31
T
fw ctl affinity -s • 30 TCP State and Benchmarking • 19
fw ctl multik stat • 32 Testing • 18
fwaccel • 10 Traffic • 7
fwaccel stats and fwaccel6 stats • 13 Troubleshooting • 41
fwaccel6 • 11 Tx queue • 7
fwaffinity.conf • 29
fwaffinty_apply • 30 U
I Upgrading with SmartUpdate • 10
Upgrading with the Command Line • 10
Increasing the Number of Concurrent
Connections • 16
Installing during a SecurePlatform Gateway
Installation • 9

# %

#

by Jens Roesen fgate stat ,

**

7+ +% cpview .
H,

(
&
**
,
%-%

fwaccel <stat|stats|conns> .
:
**

*
&

,J cpinfo
8*

,
#

fw getifs ,

?8

>

" sar ,' "
" 8

3114
8*8
" 8

cpstat <app_flag> [-f .

H,:
9

*

>
cpstat
0'
%-
" :
8

'
C8D
!

!"
flavour]
'
*

&
*
K8
sar -n EDEV +
>

"
'
#$#%

&'

(
sar -u -f /var/log/sa/sa04
+
E

"

$
<app_flag>

8
K0
C@"D
$ )
*
+
, '
'
"
cpstat fw -f policy L
0&
'
cpsizeme 7
#$:
"
8

*M*
0'
"

%-%%
)
*
+
./
"
cpstat os -f cpu
L
E
*M*
** 8

,.

M8
*

cpinfo -y all

G@ &*8
,
%-

*
"*

0&
12
310

2
4
0&
,

5126

&
'
7

5 8
06 ethtool -S .

**

cpd_sched_config print ,

!

emergendisk

& &
' "

E,)
0

' "

enabled_blades .
&
(
&

0'

!!
8
$FWDIR 79+%
*
':

:
8:
&:
&

avsu_client [-app <app>]
8
0

'
cpinfo -z -o <file>

"

?

>.
get_version <app>

9

-app *
51*
.6

* '

$CPDIR ,./
7*
;

show configuration ,
8
' "
?8* cst ?8*
,""'

0

$CPMDIR <8"
0
*
' show commands ,

""
'

ecst >,H
?8:
8:

"

8
?
$FGDIR 7 +%
*
' show asset all !'
8

"* fw ctl zdebug drop 2
*"
*8

$MDSDIR <!,
*
'
,"

=79!>2

<!,
0 show sysenv all !'
' "
"

3:

'4 cpwd_admin list !'
>!:

*8
*"

9 !8
$FW_BOOT_DIR ! '

?

&
*" asset .

>
,
1
8
11 "

show asset hardware cpca_client lscert !'

>1
*?
.

"&

/

!

"
fw tab –t <tbl> [–s]
ipsctl -a .

1

cat /var/etc/.nvram
.

&

<

-s

Expert Mode GAiA clish SPLAT cpshell IPSO clish IPSO shell

0&
&

fw tab -s
C@"D
1

@
"
""

0&

11

5@ &$' fw tab -t connections -s
L
.
*
&
""6
.
"

""
5show extended commands6 cp_conf lic get .
fw ctl multik stat ,
*
**

#
$$ cplic print !'
"

"* fw ctl pstat !'

**
8
"*
&
""':
cpstop fw lichosts

"

:
*:
'M*

/1
,

0
@
cprid
A

?
0
&'
8

*

cpstop
7

dtps lic fw ctl chain !'

"
E

8
fw
,
'
,0

""'
cpstop
79%

79+%;./+%

cpstop WebAccess

monitor

-p
*
cplic del <sig> <obj> !

8 sig"
&F obj

9&1

cp_conf sic state !'
,>

34*M
,>
1

-
cpstart cplid db_rm <sig> 2"0

<sig>"
'
(
8 cp_conf sic init <key>
*

,>
&*8
,

0
@
cprid
cpstart

"
*

cpstop cplic get <ip host|-all> 2 0

"

8 '

8 '
fwm sic_reset 2
>
*?
1 '
3>14

cprestart "&
cpstop

cpstart
"

'M
,"

'

834 2*M
>1

cpconfig

cp_conf ca init
cpridstop cplic put <-l file> >

"
file

"
cpca_client <8

>1
.:

0
*? :
, :

cprid:

2"
cpridstart > *

!" cplic put <obj> <-l 1I

"

"
file

>1
9&

C@"D
cpridrestart file> " '
obj cpca_client lscert -stat Valid

fw kill [-t sig] proc B

7

>!
?

$FWDIR/tmp/
"
&
cpca_client search <searchstring>
cprlic 2"

"8"

8
%
3,>C2<4 fwaccel <off|on> !&;&
,J
contract_util mgmt

"
<8"
,0
C@"D
fw kill -t 9 fwm cpmonitor , **

'

snoop/tcpdump/fw monitor
O
fw unloadlocal E

'
'

&
>
8 ( %
?
,
%-#%#

8
fw lslogs .

0&

8
?

M $
+
)
*
+
, '
'
"
# %

fwm logexport C@ ;'

fw.log stdout.
L
B
!&8
fw ver [-k] ,
"F

"
0

&
"&
!7
+

&
/1+
>
fwm [mds] ver

G@

"
,
fw repairlog <logfile> 2&

?

<logfile>

"%-%
L

&8
>
""

vpn ver [-k] *

0
"*

+
fw logswitch [-audit] '

3 4
8?

YY-MM-DD-HHMMSS.log
fgate ver

fw.log fw monitor)$

ver ,

0

&

fw log -c <action>

P

0'
79+%
*
7
"

,
'

*
<action>8accept
cpshared_ver ,

0

,./
7* dropreject

,
"

8:

-t
"'

3ID;;& ';"

4

!&
,J
3fwaccel off4

O8
cpview

!'
O

%#%%%#

,2

!,

>!
#

"&8
0

@
""

8
@
&

08
&
H,

fw log -f -t

8
?
"

8
9
3

8
>!
fw ctl iflist
(
&
"*
,
%-%
-t

"

&88 fw monitor -e 'accept host(192.168.1.12) and ifid=2;'
fw stat ,

"

'

&

fw log -b <starttime> .
'N
8

&
<starttime> !'

"
%#%%%#

%#%
fw stat <-l|--long>
E
-l
-s

"

8
cpstat <endtime> <endtime>. fw monitor -e 'accept src=192.168.1.12 and dst=192.168.3.3;'
fw stat <-s|--short> fw

-l

-s

&I
"I
fw fetchlogs -f <file> 7

8?
"

"

"
/HCD

8
E!

3!/,4
:
+
*

&
N Q N
fw ctl iflist !'

module
&

"

"
"
!

fw monitor -pi ipopt_strip -e 'accept udpport(53);'

fw.log

fw ctl arp [-n] !'

@'

&
-n
&
"
*
fwm logexport -i <file> -o E!
O
"

08
:
'

+
C@
8?
<file>

?
out.csv:

:
3""4

cp_conf finger get !'

?8

"8"
" fw monitor -m O -e 'accept udp and (sport>1023 or dport>1023);'
out.csv -d ',' -p -n "
3,.4

0
0

cp_conf client get !'

E>

"
3-n4 !'
9

3><:
R-4
"

%#%%%#
cp_conf admin get !'
"

"
1
fwm -p log list ,
@

0&
' "

8
? fw monitor -e 'accept host(192.168.1.12) and tracert;'
cp_conf auto get !'

" log show <nr> .
8
?
"&
<nr>
"

8

@
&
O

.,J
0
' "
>!
#
<fw1|fg1|rm|all> fw monitor -v 23 -e 'accept tcpport(80);'
#
%
# $!
01&
'0

12
cpconfig <
&
?8*

H*

add backup
&

/var/CPbackup/backups/

"
mdsconfig <!,
"
cpconfig.

" 0
3;(;G 4
1

%$--
C8D mdsenv [dms_name] ,

0"
0&

<!,

!<,
0
sysconfig add backup local
,
,1
H,

?8*
mdsstart [-m|-s] , ;

<!,

!<,
3%-

*"4
,
add backup scp ip <ip> path </pa/th/> username

cp_conf admin add <user> 1
"
user

pass

"
perm <user> interactive mdsstop [-m] '

<!,

-m

!<,
&U '

-s
<pass> <perm>

w

;

r

'
/ D
set backup restore 2
&
1

%$--
C@"D mdsstat [dms_name]|[-m] ,

<!,

!<,

"
w

" * "N
!<,
E
-m

'
<!,

set backup restore local <TAB>
cp_admin_convert C@
"
?*

cpconfig

set backup restore scp ip <ip> path </pa/th/> file cpinfo -c <dms>
cpinfo

"
!<,<dms>2""&

," !& <file> username <user> interactive
mdsenv <dms>
0
fwm lock_admin -v .

" show backups
'

& mcd <dir> 8
'

$FWDIR/<dir>

!<,
fwm lock_admin -u <user> E
"userE

-ua add snapshot 1

' "

C@" mdsstop_customer <dms> ,
8
!<,<dms>

cp_conf admin del <user> !

"
user delete snapshot add snapshot <name> [descr <”my destription”>]
mdsstart_customer <dms> ,
8
!<,<dms>

fwm expdate <dd-mmm-yyy> ,

@*

-f

set snapshot revert C@ ;"

0

' "

C8D
set snapshot export set snapshot revert <name> mds_backup [-l] [-d )
&

'
8
[-f <dd-mmm-yyyy>] " 8

@*

? D
set snapshot import set snapshot export <name> path <path> name <name> directory]
'

-d:
@
8

-l:

'
fwm expdate 31-Dec-2020 -f 31-Dec-2014

-v
A

@
?
&'
'8
"

cp_conf client add <ip> show snapshots ,

1;
E>

A

"*

$MDSDIR/conf/mds_exclude.dat

cp_conf client del <ip> upgrade_export <file>
"
$FWDIR/bin/upgrade_tools
,0
'

./mds_restore <file> 2
<!,
&
"file/*D
'
"'

migrate export <file>
?8*
3':
&F 4

H,
S8
cpca_client <8

>1
.:

0
'
mds_backup"$MDSDIR/scripts/

*? :

>1
9&
upgrade_import <file> >"
?8
8
8

"8
gtargzip"$MDS_SYSTEM/shared/

patch add cd <patch> >

<patch>
"
!
migrate import <file> '

&
?
/"':
mds_backup
backup
&

/var/CPbackup/backups/

"

8
&
lvm_manager <8
**
M

11
,

0
3;(;G 4
1

$%--
C@"D cma_migrate >"

'
8

export_database

backup [-f <file>]
"8"
0

!<,
&
8
show users ,
?8

":
E>!;>!

backup --scp <ip> <user> <pass> [-path </pa/th/>
mdscmd <subcmds> [-m mds

3" 4
<!,

<>

?8
<file>]
-u user -p pass]
"8

,
mdscmd

add user <user> 1

"
<user> restore 2
&
"

8

0
;(;G
!
vsx_util <subcommand> "
.,J
"
"

"
!<,
,
set user <user> shell ,

8

<user>

<shell>
,S8

&
8
<
&
vsx_util -h
&""
<shell>
/bin/bash

8

<user>
'

@
" snapshot

*
' "
9
*
N
"
&
* +cpstop,C@"D #
L
10

2
D
<*+!"
, '
<8"
set user <user> password ,

<user> #-
+

&8
79<
"

0+%
!<,
;
<1
snapshot --file <file>
set selfpasswd 8
'

snapshot --scp <ip> <user> <pass> <file>
(-3
4%
$$ !57 !9:;<=>
set expert-password ,

8

8
@
" revert 2&
' "
"

,"
' @

snapshot vsx stat [-v] [-l] [id] ,
.,J

.&

-v:

save config ,0

?8*
8 -l

8
.,

.,
>!
<id>

-. %

/ (!!
showusers !'

?8
,G"
" show virtual-system all

.,

.,
>!

"
cphaprob state .
1

""&
adduser <user> 1

"
<user> vsx get .

@
,

.,J
cphaprob -a if .

chsh -s <shell> <user> vsenv
2 $-.,

8

8

<user>

<shell>

,1

cphaprob -ia list .

*

0
passwd vsx set <id> ,
@

.,

>!
<id>
,

8
'

fw hastat .
1

" vsenv <id>

.,J

2 $-.,

passwd 8
@

@
"

,1
' "
cp_conf ha enable| C&

&
1 set virtual-system <id> ,
@

.,
>!
<id>
start transaction ,
*
"
1
8
"

&

disable [norestart]
fw -vs <id> unloadlocal E
'
"

.,

.,

'
@
*
"

commit

cphastart C&
;
!&
J

""&
H
vsenv <id>; fw unloadlocal fw vsx unloadall
,
-

'
@

rollback
cphastop 1
8'
<
cphastop
"8

*

show version os edition vsx sic reset <id> 2
,>

.,
<id>
7

$-
,

H,
*
3#

$+& 4

8

cphaprob syncstat .

'

'
**
2

-reset
vsenv <id>; fw vsx sicreset ,

.,J

2 $-.,

set edition default ,

&
#

$+&

$+&

,
$$

*

32-bit|64-bit cpinfo -x <id> ,

*8

.,
>!
<id>
)

21<
3
%)
8

.<4

fw ctl pstat .

'

**
,
$$
vpn -vs <id> debug trunc C" '
T
"
8:
&
>BC
T
./
&8
(* fw ctl setsync <off|start> ,

'M*

fw -vs <id> getifs .
0

.,
A

vpn tu ,

"
&
./
E*
8"

'

fw -d fullsync <member-ip> ,

'M*

&888
vsenv <id>; fw getifs .,
"

-vs <id>

, '
1*
3,14

cphaconf set_ccp ?8

34

fw tab -vs <id> -t <table> .

&

0
' "
<id>
,

vpn shell ,

./
<broadcast|multicast>
"*
"8
)'

"*
vsenv <id>; fw tab -t <table>

.,J

2 $-.,

vpn debug ikeon|ikeoff !&8
>BC
$FWDIR/log/ike.elg1'M
ike.elg
cphaconf debug_data .
"*
<1

vsx vspurge 2"0

.,J
' "

.,
?8

>BC.

,
-$ clusterXL_admin [-p] "

8
"
0
&'
8 8

fw monitor -v <id> -e .
O

0
' "

>!
<id>
vpn debug on|off !&8
./

$FWDIR/log/vpnd.elg1'M
vpnd.elg
<up|down> 0
,00

&
-p
'accept;'

1ID

fw monitor

-v

-vs.

>BC.

,
-$ show vrrp interfaces !

.22

7

&
00
cphaprob -vs <id> state .
1

.
,' "

5
.
vpn debug trunc

"
8:
&
>BC
T
./
&8 '

show vrrp

iclid
,' "
16
"

?8
vpn drv stat ,

./+%

" cphaprob tablestat .
>

>!

""& cphaprob -vs <id> register 28

0

.,
<id>

@
vpn overlap_encdom ,:

':
08
./
" cphaprob igmp .
><

"*
"
""&
3'

.,
1;.,,4
vpn macutil <user> ,
<1

,
2"

<user> -
+
10

2
D
J
2@

2 @ $linux_command -z <id> >
2

@
ifconfigiparpping
#-#
+

&
0

J
traceroute -Z <id> netstatEZtraceroute.
-%
+

&
./

,

,

$-
+

&8
./!
" # -
+

&
0

J
+
10 1

N
""

2

-vs <id>
9

#
+

8

0
./
&8:
>BC
&8

79
<
$$
+
>
K8

8
0
0
'
(
0

8
@

vsenv <id>
&
8

""

*0
""
)A+/+,1
,G":
,9:
," :
J:
,J:
7+ +%:
0+%:
.,J:
>,H:
./+%;E<+%
C8

11

8
"

,(
8:

BSDVWHG,PDJHBSQJ31*,PDJHîSL[HOV6FDOHG KWWSVFRPPXQLW\FKHFNSRLQWFRPOHJDF\IVRQOLQHFKHFNSRLQWBSDVWHG,PDJHBSQJ
RI
BSDVWHG,PDJHBSQJ31*,PDJHîSL[HOV6FDOHG KWWSVFRPPXQLW\FKHFNSRLQWFRPOHJDF\IVRQOLQHFKHFNSRLQWBSDVWHG,PDJHBSQJ
RI

04-CCTE Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

04-CCTE Guide

Uploaded by

Copyright:

Available Formats

Check Point®

Troubleshooting and Debugging Tools

Mandatory Support Information page 1

Mandatory Support Information

To disable the Kernel debugging, execute:

The debug file is located under $FWDIR/log/fwm.elg

The debug file is located under: $FWDIR/log/ahttpd.elg* or $FWDIR/log/aftpd.elg* or

The debug file is located under: $FWDIR/log/ahttpd.elg*

SMTP Security Server

The debug file is located under $FWDIR/log/asmtpd.elg*

The debug file is located under $FWDIR/log/mdq.elg*

The debug file is located under: $FWDIR/log/asessiond.elg*

For Telnet to port 259, execute:

The debug file is located under: $FWDIR/log/ahclientd.elg*

The debug file is located under $FWDIR/log/ike.elg and $FWDIR/log/vpnd.elg

The debug file is located under /opt/CPsuit-R60/fw1/log/mds.elg

Kernel debug for packet filter analysis

To turn the debug on, under: $CVPNDIR/conf/httpd.conf change LogLevel to debug.

% fw ctl kdebug –T –f > <output file>

Additional kernel debug options for InterSpect:

Kernel debug for Packet Drop, execute:

Kernel debug for SmartDefense TCP Streaming, execute:

Kernel debug for Dynamic list (SAM), execute:

SNX – SSL Network Extender debugging

Debug can be found at $FWDIR/log/vpnd.elg.

Open the Command Line interface window and execute:

The debug file is located under:

The debug file is located under %APPDATA%\Check Point\extender\activex.log .

Document Title: How to use fw monitor

TYPOGRAPHIC CONVENTIONS USED IN THIS PAPER............................................................................................5

COMMAND SYNTAX ....................................................................................................................................................7

STANDARD USAGE ...................................................................................................................................................12

Using fw monitor .....................................................................................................................................................12

ADVANCED USAGE ...................................................................................................................................................14

Capture masks ........................................................................................................................................................14

INSPECT FW MONITOR FILES ..................................................................................................................................39

Using snoop to inspect fw monitor files ...................................................................................................................39

SRFW – FW MONITOR ON THE CLIENT SIDE .........................................................................................................64

How to use fw monitor Page 2 of 70

Secure Knowledge Links.........................................................................................................................................66

Multicast MAC addresses........................................................................................................................................69

How to use fw monitor Page 3 of 70

How to use fw monitor Page 4 of 70

Typeface or Meaning Example

AabBcC123 What you type, when

How to use fw monitor Page 5 of 70

How to use fw monitor Page 6 of 70

Use ^C (that is Control + C) to stop fw monitor from capturing packets.

Printing the UUID or the SUUID [-u|s]

Flush standard output [-i]

Debugging fw monitor [-d] / [-D]

Filter fw monitor packets <{-e expr}+|-f <filter-file|->>

How to use fw monitor Page 7 of 70

[Expert@cpmodule]# echo "accept [9:1]=1;" >myfilter.pf

How to use fw monitor Page 8 of 70

Limit the packet length [-l len]

Capture masks [-m mask]

Print packet/payload data [-x offset[,len]]

How to use fw monitor Page 9 of 70

[Expert@cpmodule]# fw monitor -e 'accept ip_p=1;' -o ping.cap

Use absolute chain positions [-a]

How to use fw monitor Page 10 of 70

[Expert@cpmodule]# fw monitor -ci 3 -o dump1.cap

3 (inbound) * 2 (pre/post) + 3 (outbound) * 2 (pre/post) = 12 packets.