White Paper:

Fw Monitor
A troubleshooting tool
May 2005
 White Paper: fw Monitoring May2005

Table of Contents

Introduction............................................................................................................................................................................................................. 2
The OSI Model – a troubleshooting framework........................................................................................................................................... 2
Running fw monitor ............................................................................................................................................................................................. 2
Anatomy of a filter expression ................................................................................................................................................................. 3
Output of fw monitor .................................................................................................................................................................................. 3
The 4 Capture Points.................................................................................................................................................................................... 3
Limitations of fw monitor ......................................................................................................................................................................... 4
Commonly Used Options ..................................................................................................................................................................................... 4
Write output to file [-o <file>] .................................................................................................................................................................. 4
Limit the packet length [-l len]................................................................................................................................................................. 4
Capture masks [-m mask] .......................................................................................................................................................................... 5
Example Scenarios................................................................................................................................................................................................. 5
Capturing all traffic to or from a host .................................................................................................................................................... 5
Capturing VRRP traffic ................................................................................................................................................................................. 5
Creating complex filters.............................................................................................................................................................................. 5
Alternate versions of the Complex Filter............................................................................................................................................... 6
Troubleshooting a NATed Connection ................................................................................................................................................... 6
Advanced filter expressions: using lists ................................................................................................................................................ 7
References....................................................................................................................................................................................................... 7

1
 White Paper: Push to Talk Technology
Introduction
fw monitor is a useful packet capture tool provided by
Check Point as a part of VPN-1/FireWall-1. It allows a
network troubleshooter to capture packets as they pass
through the VPN-1/FireWall-1 Enforcement Module. In
order to use the tool, however, the prospective network
troubleshooter must first understand the fundamentals
of computer networking. We discuss the basics of using
the fw monitor utility, including some common optional
parameters, which can be very useful. Finally, we end
with a series of examples illustrated network
troubleshooting.
The OSI Model – a troubleshooting
framework
As all Students of Networking know, it is mandatory that
we discuss the OSI Model before diving into a packet
capture tool.
Figure 1: The OSI Model and its mapping to TCP/IP protocols
The OSI Model provides the framework for our
troubleshooting efforts. It is a theoretical model, and
while it is very useful in organizing our thinking about
data communications, it does not map one-to-one with
current popular protocols. The important thing the model
shows us is that network communications are modular –
2
March 2005
each layer performs a subset of the functions needed for
two devices to communicate. The protocols are then
linked together to enable the communication.
The Physical Layer handles the bits on the wire. A Physical
Layer Protocol specification will define how bits are
encoded into electrical signals and how devices should
interpret bit patterns as bytes. For example, the IEEE
802.3 specification for Ethernet mandates that 100BASE-
TX Ethernet will use a 4B5B binary encoding mechanism
to convert bits into electrical signals.
A Data Link Protocol provides the specifications that allow
a network interface card (NIC) to communicate with
another NIC. For example, Ethernet defines the MAC
address and how to craft a data frame so that a NIC can
transmit the frame and that a receiving NIC can receive
and interpret the frame of data.
The Transport Layer provides for program-to-program
communication. For example, my client may have a web
session and a terminal session with the same server host.
At the network layer, the communications look the same
– packets between my client IP address and the server IP
Address. At the Transport Layer, however, we see TCP Port
numbers, which identify which packets belong to which
sessions.
The remaining layers, Session, Presentation and
Application, are less important in the TCP/IP suite of
protocols and, therefore, are less important to most
network troubleshooting. It should be pointed out that
the Application Layer is not the application itself, for
example a web server. Rather, the Application Layer
Protocol is often like an API for the client and server
applications. The web client sets an HTTP GET request,
and the web server returns data, and the HTTP Protocol
specifies how the GET request is formatted and how the
data should be returned.
Following the data as it passes through the TCP Stack of
the web server illustrates the second key OSI Model
concept of Encapsulation. Each layer takes the output of
the previous layer and encapsulates it, wrapping the data
in its header. At the other end, the recipient simply peels
off each layer like an onion and passes the data up to the
next Layer.
 White Paper: Push to Talk Technology
Figure 2: Encapsulation of the data by each layer of the Network Stack
As shown in Figure 2, the web server has a chunk of data,
for example, the text of a web page. The application
wraps the data in an HTTP data unit and passes to the TCP
layer, which resides in the kernel. The TCP layer processes
the entire HTTP data unit by segmenting the data into
chunks and placing a TCP header on the front of each
chunk. TCP then hands its data to the IP layer, which does
the same thing, treating the entire TCP data unit as one
data payload, appending an IP header and passing the
entire thing to the Ethernet driver. The Ethernet driver
appends its header and, in the case of Ethernet, a trailing
checksum and passes the frame to the physical NIC for
transmission on the wire.
Thus the frame on the wire contains each protocol
header in succession and then finally the chunk of data
being transferred from server to client. We can capture
this frame with a packet capture tool and see what the
headers and data are. In order to understand what we
are looking at, we need to know the protocol which is
being used. A Protocol is just a set of rules that both
sides understand. For example, because of the IP Protocol
Specification, hosts know which 4 bytes of the 20 byte IP
header is the destination address.
Basically, network troubleshooting reduces to mapping,
at each layer, where the data unit is going to and where
is it coming from. That information is then compared
against expectations until the problem is identified. Our
expectations are built from our knowledge of how the
protocols are specified to work and from our
understanding of the network topology at each OSI layer.
Most network connectivity issues can be resolved by
analyzing the behavior of network communications at
the first 4 layers of connectivity. The network
March 2005
troubleshooter should start at the bottom and work
her way up. Check that the wire is plugged in or that
the WEP keys have been typed correctly. Check that the
host is able to find the MAC address needed to transmit
a frame. Check that the router is forwarding the packet
out of the correct NIC to reach the end host. Check that
the correct port number is being used. Network
Troubleshooting by protocol analysis is rarely that
hard, but it can be time consuming to discern each
communication session from the individual packets
and frames.
Running fw monitor
The fw monitor command is relatively straightforward to
use. One can just run the command by itself
firewall[admin]# fw monitor
and the utility will flood you with data. To end the
capture, simple press Ctrl-C (i.e., the Control key and the c
key simultaneously).
In most situations, there is simply too much data to
analyze. fw monitor uses short VPN-1/FireWall-1 Inspect
scripts to determine which data to capture and present.
Inspect scripts use an offset notation to match specific
bytes within a packet. Luckily, Check Point has defined a
number of keywords to represent these offset notation
entries. These definitions can be found in the various
$FWDIR/lib/*.def files, especially $FWDIR/lib/tcpip.def.
One example is the src keyword, which is equivalent to
the ip_src keyword which is equivalent to the offset [12,
b]. The src keyword matches the given parameter against
the IP Source address in the packets. For example, to
match all packets coming from a particular host, we could
use
2
 White Paper: fw Monitoring May2005

firewall[admin]# fw monitor –e “accept the length as Check Point sees the datagram. This length
src=10.10.10.51;” comes from Check Point’s Virtual Defragmentation Engine
and can be different from the length as reported in the IP
and the output would show every packet received by Header for the packet. The line ends with a decode of the
firewall with an IP Source address of 10.10.10.51. IP header: Source IP to Destination IP, decode of the IP
Protocol field, display of the IP Length field and of the ID
Anatomy of a filter expression field of the IP Header.
In the above command, the –e tells the fw monitor utility
to expect a filter expression. The filter expression must be The 4 Capture Points
isolated from the shell by quotes so that the entire As mentioned above, the default fw monitor output
expression is passed to the fw monitor utility. includes four lines for each packet passed by the firewall.
The four lines correspond to the four main capture points
The first part of the quoted expression tells fw monitor to provided by the Enforcement Module:
accept packets that match the following expression. The
expression src=10.10.10.51 describes only packets with a pre-inbound inspection ( i )
Source IP Address of 10.10.10.51. No packets coming
from any other source nor packets destined for post-inbound inspection ( I )
10.10.10.51 will be included in the output. Finally, the pre-outbound inspection ( o )
ending semicolon ( ; ) is critical. Frequently, when filter
post-outbound inspection ( O ).
expressions are suggested using a sans-serif or
proportional font, the semicolon becomes invisible next The inclusion of the Capture Point in the decode is,
to the quotation mark. More than one engineer has spent perhaps, the most import feature of fw monitor for the
hours trying different filter expressions in vain only to network troubleshooter. VPN-1/FireWall-1, by default,
finally realize that the semicolon was missing. compares network traffic against its policy and state
tables both when the packet is received (inbound) as well
as immediately
before the packet is
transmitted
(outbound). The four
primary capture
points correspond to
points immediately
before and after the
VPN-1/FireWall-1
inspection points. If
we see that a packet
was captured only
prior to an
inspection but not
after and inspection,
we can conclude
Figure 3: Default output of fw monitor command that some aspect of
firewall policy is the
cause of our network problem.
Output of fw monitor
By default, fw monitor provides 4 lines of decode for each For example, if a packet only generates one line of output
packet passed by VPN-1/FireWall-1. If the packet is marked with the pre-inbound inspection ( i ) identifier,
carrying a TCP, UDP or ICMP data unit, as in Figure 3, fw we can be confident that the VPN-1/FireWall-1 policy is
monitor will display a second line decoding that protocol. causing the packet to be dropped. The VPN-1/FireWall-1
The first element of the decode is the interface on which policy and log viewer should be used to figure out which
the packet is either being received or being sent. Next, we rule is causing the problem.
have the Capture Point identifier ( i, I, o, O) followed by

3
 White Paper: Push to Talk Technology
Another example would be if only lines for inbound
inspection ( i, I ) are shown but outbound inspection ( o,
O ) are missing. This would indicate that the packet is
either terminating at the firewall itself or that routing
has been misconfigured and the routing engine of
thedevice is blackholing the packet.
If the expected packet doesn’t even produce any inbound
inspection decode lines, this means either that the filter
expression is incorrect or that the packet is never making
it to the Enforcement Module for inspection. Other tools
would then be needed to see what is going on outside
the firewall device.
Limitations of fw monitor
Unlike many packet capture utilities, fw monitor cannot
show Data Link Layer or lower protocol information. The
NIC strips the Data Link Layer information before handing
the packet to the VPN-1/FireWall-1 module. On the up
side, fw monitor can, as we have seen, show the packet
at different inbound and outbound capture points along
the way.
Using the OSI model as our troubleshooting guide, it
would be wise to first verify that the network traffic is
2.
flowing correctly at the Data Link Layer before using fw
monitor to analyze traffic at the Network Layer. Tools
like tcpdump, snoop and 3rd party protocol analyzers can
be used to check the transmission of data at the Data Link
Layer. Many 3rd party analyzers can even detect Physical
Layer problems. 3.
Misconfigured Proxy ARP is an example of a problem that
fw monitor simply cannot solve. If hosts are not even
transmitting the frames to the NIC of the firewall, VPN-
1/FireWall-1 will never inspect the packet and fw monitor
will never provide and lines of decode to analyze.
Tcpdump, however, can capture traffic not transmitted
directly to the firewall’s NIC and can display the incorrect
hardware addressing.
Commonly Used Options
The following options extend the usefulness of fw
monitor.
Write output to file [-o <file>]
The –o <file> option is very useful for getting the data out
of the terminal window and into a full featured protocol
analyzer like Ethereal. Ethereal can decode a far greater
array of Transport, Session, Presentation and Application
layer protocols. It provides various views of the packet
March 2005
data as well as more advanced filtering options, thereby
making it easier to figure out what is going on.
Instead of outputting decoded packets to the terminal,
fw monitor writes the raw packet binary data to a file.
There are several limitations to this output, however:
1. Because fw monitor never sees the Data Link Layer
data, it cannot capture the Data Link Layer data. fw
monitor, however, uses the bytes reserved for Data
Link Layer header information to encode the
Interface and Capture Point information presented in
the normal fw monitor output. To quote Check
Points “How to use fw monitor 10-Jul-2003”
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
Packet capture files can become quite large. Care
must be taken to limit the traffic captured by
carefully using filter expressions. The Limit the packet
length [-l len] option can also help reduce this
problem.
Unless the Limit the packet length option is used,
packet capture files will contain potentially sensitive
data from the network connections being captured.
Care must be taken with the resulting file
4. In order for the packet capture to be useful, it must
first be transferred off the firewall.
It is good practice to chose a file name that ends in a
“.pcap” or “.dmp” extension. This makes it easier for
Ethereal on a Windows platform to open the file directly.
fw-1[admin]# fw monitor –o monitor.pcap –e “accept
src=10.10.10.51;”
Limit the packet length [-l len]
The Limit the packet length option can help overcome
some of the problems with using the Write output to file
option. Usually the network troubleshooter is only
interested in the header data. The actual data being
transferred can cause the packet capture file to swell to
4
 White Paper: fw Monitoring
enormous size and frequently contains sensitive
information. By carefully choosing a packet length (len)
value to capture, both of the problems can be reduced.
The question then is, what len value to use? The
parameter defines the number of bytes of the captured
frame which should be included in the packet capture file.
The IP header is usually contained within the first 38
bytes of the frame, and the TCP header is usually within
the first 58 bytes. NetBios related protocols, such as
Microsoft’s SMB implementation, and RPC (Remote
Procedure Call) related protocols, such as Sun’s NFS
(Network File System) protocol, can frequently require
more that 200 bytes of frame data. Experience and trial
and error become the usually ways a network
troubleshooter decides which len values to use.
As a starting point, try a value of 300 if capturing
Microsoft or Sun implemented protocols. Try a value of
128 if capturing standard IETF defined protocols like
HTTP, as in the following example:
fw-1[admin]# fw monitor –o monitor.pcap –l 128 –e
“accept src=10.10.10.51;”
Capture masks [-m mask]
This option is particularly useful when analyzing standard
fw monitor output on the command line. Frequently we
only care if the packet made it through the firewall, and Likewise, DNS traffic uses UDP Port 53, so to capture all
the post-inbound inspection ( I ) and the pre-outbound
inspection ( o ) decode lines just make the output harder
to read.
The mask parameter in its simplest form is just a
sequence of the the iIoO characters used to identify the
desired capture points. Therefore, if we only want to
capture output from the pre-inbound inspection ( i ) and
post-outbound inspection ( O ) Capture Points, we could
modify our fw monitor command like so:
firewall[admin]# fw monitor –e “accept
src=10.10.10.51;” –m iO
Example Scenarios
In this section, we will describe a number of scenarios,
the filter expression needed to capture the relevant traffic
and an explanation of the analysis. Troubleshooting of
network problems requires an understanding both of the
network topology as well as of the protocols being used.
A full discussion of the relevant protocols is outside the
5
May2005
scope of this tutorial, but relevant facts regarding the
protocols will be provided.
Capturing all traffic to or from a host
The simple filter example used previously will only
capture traffic from the host 10.10.10.51. If you need to
see all traffic to or from a particular host use:
–e “accept src=10.10.10.51 or dst=10.10.10.51;”
Notice the use of the Logical Operator or. We want to see
traffic in both directions, i.e., packets either destined for
10.10.10.51 or coming from 10.10.10.51. A common
mistake is to use the logical operator and. Such a
construction, however, results in no packets being
matched, because ordinarily there are no network
packets from a particular IP address destined for that
same IP address .
Capturing all traffic of a specific service
To capture all traffic related to a specific service, the
correct identifier must be know. For example, to capture
all web traffic, which uses TCP Port 80, the following filter
can be used:
-e “accept sport=80 or dport=80;”
DNS traffic we can use:
-e “accept sport=53 or dport=53;”
Capturing VRRP traffic
The VRRP protocol header immediately follows the IP
header. The IP Protocol value of 112 has been assigned
to VRRP. To filter on an IP Protocol value, the ip_p macro
must be used. The following expression will capture all
VRRP traffic:
-e “accept ip_p = 112;”
Creating complex filters
In addition to the logical operator or, fw monitor
provides several additional logical operators:
or Logical OR
“,” and Both the comma and the keyword and work as a
Logical AND
xor Logical XOR (not commonly used)
Not Logical NOT (not commonly used)
 White Paper: Push to Talk Technology
In addition to the relational operator =, fw monitor
provides several additional logical operators:
= or Both the equals sign and the keyword is
is work as the relational operator EQUAL
!= or Both the exclamation point/equals sign combination
is and the keyword is not work as the relational
not operator NOT EQUAL
< Relational operator LESS THAN
> Relational operator GREATER THAN
<= Relational operator LESS THAN OR EQUAL TO
>= Relational operator GREATER THAN OR EQUAL
TO
Let’s take the scenario where we need to examine all
web traffic between two hosts. To limit the traffic to only
the two hosts in question we need an expression that
captures only traffic between the two hosts
(src=10.10.10.51 and dst=192.168.0.101) or
(src=192.168.0.101 and dst=10.10.10.51)
Now we must add an expression to capture only web
traffic between the two hosts (note, we are using the
backslash character ( \ ) to escape a newline character
inserted to make the line readable)
((src=10.10.10.51 and
dst=192.168.0.101)or(src=192.168.0.101 and
dst=10.10.10.51)) \
and (sport=80 or dport=80)
In a UNIX csh environment, the final command to capture
only port 80 web traffic between hosts 10.10.10.51 and
192.168.0.101 would be:
fw1[admin]# fw monitor –e “((src=10.10.10.51 and
dst=192.168.0.101) \ or(src=192.168.0.101 and
dst=10.10.10.51)) and (sport=80 or dport=80) ;”
The importance of using parentheses in complex filters
cannot be overestimated.
Alternate versions of the Complex Filter
Check Point’s Inspect scripting language is very versatile.
One example would be to use multiple accept statements
in a single filter expression. The same expression to
capture all port 80 web traffic between hosts 10.10.10.51
and 192.168.0.101 can be written as:
March 2005
-e “accept src=10.10.10.51 and dst=192.168.0.101 and
sport=80 ; \
accept src=192.168.0.101 and dst=10.10.10.51 and
dport=80) ;”
As the logical operator “and” can be replaced with a
comma ( , ), original statement can be written even more
confusingly as:
fw1[admin]# fw monitor –e
“((src=10.10.10.51,dst=192.168.0.101) \
or(src=192.168.0.101,dst=10.10.10.51)),(sport=80 or
dport=80) ;”
Troubleshooting a NATed Connection
If one of the hosts is NATed at the firewall, the above
complex filter expression will not capture the packet at
all four inspection capture points. After the NAT takes
place, the packet will no longer match the expression and
will no longer be captured by fw monitor.
In the case of Static NAT, a solution is obvious: just add
the static NAT address to the expression. If the server
10.10.10.51 is NATed to 172.16.10.51, then the filter
expression becomes:
fw1[admin]# fw monitor –e “(((src=10.10.10.51 or
src=172.16.10.51) \
and dst=192.168.0.101) or (src=192.168.0.101 and
(dst=172.16.10.51 or \
dst=10.10.10.51))) and (sport=80 or dport=80)”
As the example’s inscrutability demonstrates, just adding
additional parameters may not be the best way to
proceed. When dealing with Hide NAT, the potential for
capturing unrelated packets becomes greater as many
hosts are translated to the Hide NAT address.
Perhaps we don’t need to see the missing packet,
because the existence of the other packets implies its
existence. In that case, the statement remains the same
as presented in the Complex Filter example.
Perhaps we can limit the packet capture sufficiently by
only filtering on the remote host IP address. For example,
if our client is the only local client connecting to the
remote server, we can filter on the remote server IP
address or remote server IP address and TCP Port
numbers and only capture the desired communications,
6
 White Paper: fw Monitoring May2005

including NATed traffic. In this case, we can actually References

simplify the filter expression: Check Point, “How to use fw monitor”, Jul 10, 2003.
Available from the Next Generation Utilities page
fw1[admin]# fw monitor –e “(src=10.10.10.51 or (“http://www.checkpoint.com/techsupport/downloadsng
dst=10.10.10.51) and \ /utilities.html”).
(sport=80 or dport=80)”

In truly complicated situations, such as where many hosts

and many servers are all using the same Application Layer
protocol to exchange data, the use of multiple accept
statements, as illustrated in the section “Alternative
versions of the complex filter”, can become a necessity.

Advanced filter expressions: using lists

Check Point provides a list feature that allows both for
the definition of specific hosts as well as the definition of
address ranges in filter expressions. A list is first defined,
and then that list can be used by name in later IP address
matching.

For example, say we need to find out if any address in a

particular subnet is accessing a commonly used server.
We could define a list that includes the subnet by using
the ‘<‘ and ‘>‘ to define a range of addresses:

fw1[admin]# fw monitor –e “[troubleNet] = {

<192.168.10.0, 192.168.10.255> } ; \

accept (src in troubleNet and dst=10.10.10.51) ;”

We can also define multiple hosts or multiple networks in

a list definition:
–e “[badHosts] = { 192.168.10.53, 192.168.21.18,
192.168.101.186 } ; \

accept (src in badHosts and dst=10.10.10.51) ;”

Saving output to a text file

Rather then using the Write output to file [-o <file>] to
capture raw packet data, simple shell redirection can be
used to capture the default fw monitor output to a file.
On a UNIX type system, simply use the redirection
operator > like so:

fw1[admin]# fw monitor –e “accept src=10.10.10.51;” >

monoutput.txt

and the file monoutput.txt will be created with the

standard output of the command.

7
About Nokia
Nokia is the world leader in mobile communications, driving the growth and sustainability of the broader
mobility industry. Nokia is dedicated to enhancing people's lives and productivity by providing easy-to-use
and secure products like mobile phones, and solutions for imaging, games, media, mobile network
operators and businesses. Nokia is a broadly held company with listings on five major exchanges.

For more information, please visit http://www.nokia.com/forbusiness

Americas
Nokia
313 Fairchild Drive, Mountain View, CA 94043
Tel: 1 877 997 9199
Email: mobile.business.americas@nokia.com
Europe, Middle East and Africa
Nokia
Nokia House, Summit Avenue
Southwood, Hampshire, GU14 ONG, UK
Tel UK: +44 161 601 8908
Tel France: +33 170 708 166
Email: mobile.business.emea@nokia.com
Asia Pacific
Nokia
438B Alexandra Road
#07-00 Alexandra Technopark, Singapore 119968
Tel: +65 6588 3364
Email: mobile.business.apac@nokia.com
www.nokia.com

Copyright © 2005 Nokia. All rights reserved. Nokia and Nokia Connecting People are registered trademarks of Nokia Corporation. Other trademarks mentioned are the
property of their respective owners. Nokia operates a policy of continuous development. Therefore we reserve the right to make changes and improvements to any of
the products described in this document without prior notice. Under no circumstances shall Nokia be responsible for any loss of data or income or any direct, special,
incidental, consequential or indirect damages howsoever caused.