Header/footer test page

[My Favorites](https://support.checkpoint.com/favorites)

Solution ID: sk30583

* * *

Technical Level:

Basic

[Email](mailto:?subject=sk30583%20-%20What%20is%20FW%20Monitor?&body=Solution%20Title:%20What%20is%20FW%20Monitor?%0D%0ASolution%20ID:%20sk30583%0D%0ASolution%20Link:%20https://support.checkpoint.com/results/sk/sk30583%0D%0A-------------------------------------------------------------%0D%0AFor%20Disclaimer%20of%20Warranty%20and%20Copyright%20info:%20http://www.checkpoint.com/copyright.html)

[Print](https://support.checkpoint.com/results/sk/sk30583#)

# What is FW Monitor?

ProductCluster - 3rd-party, ClusterXL, CoreXL, IPS, IPSec VPN, SecureXL, Security Gateways, VSX (Traditional)

VersionR80.10 (EOS), R80.20 (EOS), R80.30 (EOS), R80.40 (EOS), R81 (EOS), R81.10 (EOS), R81.20

Last Modified2026-02-15

## Solution

**Table of Contents:**

01. Introduction

02. Warnings

03. FW Monitor Features

04. FW Monitor Functionality

05. FW Monitor Syntax and Usage

1. Syntax

2. Comparison with TCPdump

3. Using the UUID feature
06. SecureClient Syntax

07. Capture Examples of "-e" flag

1. Usual Capture

2. Host Specific Capture

3. Port Specific Capture

4. Protocol Specific Capture

5. Protocol Options Specific Capture

6. Bytes Specific Capture

7. Network Specific Capture

8. Some Examples
08. Capture Examples of "-F" flag

1. Usual Capture

2. Host Specific Capture

3. Port Specific Capture

4. Protocol Specific Capture
09. Related Documentation

10. Related Solutions

## (1) Introduction

Check Point's _**FW Monitor**_ is a powerful built-in tool for capturing network traffic at the packet level. The _FW Monitor_ utility captures network packets at multiple capture points along the FireWall inspection chains. These captured packets can be inspected later using the WireShark (available for free from [www.wireshark.org](http://www.wireshark.org/)).

## (2) Warnings

- Anything related to policy installation or policy unloading on Security Gateway, will cause _FW Monitor_ to exit.

- It is supported to run _only_ a single instance of _FW Monitor_ at any given time.

- Do not modify Check Point kernel tables used in the security policy while _FW Monitor_ is running. Otherwise, unexpected behavior may result (including a system crash).

- Packets are defragmented as they leave the Security Gateway in both the inbound and outbound directions.

- If SecureXL is enabled on the Security Gateway, then _FW Monitor_ and _tcpdump_ will show only the **non**-accelerated packets (e.g., 'TCP SYN' will be shown, and 'TCP ACK' will not).

- **Important Note:** Traffic captures can be misleading when working with SecureXL since both FW Monitor and TCPdump do not always show 'real' packets that are going out to the network. This is related to the way the SecureXL kernel driver is attached to the network adapter itself. When using SecureXL to confirm whether packets are being handled correctly, either capture the traffic on the directly connected router / switch, or disable SecureXL.

- From R80.20 Jumbo Hotfix Accumulator Take 73, the FW Monitor supports monitoring of accelerated traffic by default.

- From R80.20, the FW Monitor can show the traffic accelerated with SecureXL.
- From R80.30 Jumbo Hotfix Accumulator - General Availability Take 215, added ability to FW Monitor to support monitoring of accelerated traffic by default, except for the "`-e`" flag for FW Monitor, which is not supported on SecureXL.

### Monitored traffic

- From R80.20, the 1st accelerated packet is monitored only in the inbound (i).
- From R80.20 Jumbo Hotfix Accumulator Take 73, the accelerated inbound (i) traffic and accelerated outbound (O) traffic is monitored in the Fast Path.
- From R80.20 Jumbo Hotfix Accumulator Take 117, the Slow Path, the Medium Path, and the Fast Path are monitored.
- From R80.30, the default behavior is like before R80.20 Jumbo Hotfix Accumulator Take 72.
- From R80.40 and in R80.30 Jumbo Hotfix Accumulator Take 215 and above, the default behavior is to monitor all traffic.

### Filtering options

- From R80.20 Jumbo Hotfix Accumulator Take 73, using the "`-e`" flag will not filter the accelerated traffic (all accelerated traffic is monitored). To filter the accelerated traffic, use the "`-F`" flag.
- From R80.20 Jumbo Hotfix Accumulator Take 117, using the "`-e`" flag will filter out all accelerated traffic. To filter and monitor the accelerated traffic, use the "`-F`" flag.
- You can freely use the “-F” flag in these versions:

- R80.40 and above
  - R80.30 Jumbo Hotfix Accumulator Take 215 and above
  - R80.20 Jumbo Hotfix Accumulator Take 173 and above

If you use the "`-e`" flag, the filtering applies to the non-accelerated traffic, and accelerated traffic is not shown at all.
- **Important:**

A limitation exists when you use filters ("`-F`" flag for "`fw monitor`" and "`-F`" / "`-H`" flags for "`fw ctl debug`") for both "`fw monitor`" and "`fw ctl debug`" simultaneously. Running any of these commands with a debug filter overrides the debug filter used for pre-existing debug commands.

**Currently, it is not supported to run both of these commands simultaneously with a debug filter - "`fw monitor -F`" and "`fw ctl debug -F`" / "`fw ctl debug -H`".**

Only the filter for the last command that was run is applied. The data for the previous command will stop being filtered as soon as a new command is run, which means that all data is received unfiltered. **This may have significant performance impact.**

If you need filtered packet capture during a kernel debug “`fw ctl debug`” session, we recommend to use "`cppcap`" ( [sk141412](https://support.checkpoint.com/results/sk/sk141412)) instead of "`fw monitor`".

## (3) FW Monitor Features

In many deployment and support scenarios, capturing network packets is an essential functionality. The _tcpdump_ / _snoop_ utilities are normally used for this task. The _FW Monitor_ utility provides an even better functionality, but omits many of the requirements and the risks associated with these tools:

- _No Security Flaws_
_tcpdump_ / _snoop_ are normally used with NICs in promiscuous mode. Unfortunately, promiscuous mode allows remote attacks against these tools. Check Point's _FW Monitor_ does not use 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_ / _snoop_, because of their security risks.
- _Available on FireWall Installations_
_FW Monitor_ is a built-in tool that does not need a separate installation, or licensing.
- _Multiple Capture Positions within the FireWall Kernel Module Chains_
_FW Monitor_ allows capturing packets at multiple capture positions within the Security Gateway kernel module chains, both for inbound and outbound packets. This enables to trace a packet through the different layers of the Security Gateway.
- _Same Tool and Syntax on All Platforms_
_FW Monitor_ is available on all different platforms. _tcpdump_ / _snoop_ are often platform-dependent, or have specific "enhancements" on certain platforms. _FW Monitor_ and all its related functionality and syntax are identical across all platforms.

Normally, Check Point kernel modules are used to perform several functions on packets, such as filtering, encryption and decryption, QoS, etc. _FW Monitor_ adds its modules to capture packets. _FW Monitor_ can capture all packets that are seen and/or forwarded by the Security Gateway.

## (4) FW Monitor Functionality

There are different inspection points when a packet passes through a Security Gateway.

**Note** \- The Inbound and Outbound traffic direction relates to each specific packet, and not to the connection.

- Inbound:

|     |     |     |
| --- | --- | --- |
| Name of inspection point | Relation to the FireWall<br>Virtual Machine | Notion of inspection point<br>in the FW Monitor output |
| Pre-Inbound | Before the inbound FireWall VM | i (for example, `eth4:i`) |
| Post-Inbound | After the inbound FireWall VM | I (for example, `eth4:I`) |
| Pre-Inbound VPN | Inbound before decryption | id (for example, `eth4:id`) |
| Post-Inbound VPN | Inbound after decryption | ID (for example, `eth4:ID`) |
| Pre-Inbound QoS | Inbound before QoS | iq (for example, `eth4:iq`) |
| Post-Inbound QoS | Inbound after QoS | IQ (for example, `eth4:IQ`) |

- Outbound:

|     |     |     |
| --- | --- | --- |
| Name of inspection point | Relation to the FireWall<br>Virtual Machine | Notion of inspection point<br>in the FW Monitor output |
| Pre-Outbound | Before the outbound FireWall VM | o (for example, `eth4:o`) |
| Post-Outbound | After the outbound FireWall VM | O (for example, `eth4:O`) |
| Pre-Outbound VPN | Outbound before encryption | e (for example, `eth4:e`) |
| Post-Outbound VPN | Outbound after encryption | E (for example, `eth4:E`) |
| Pre-Outbound QoS | Outbound before QoS | oq (for example, `eth4:oq`) |
| Post-Outbound QoS | Outbound after QoS | OQ (for example, `eth4:OQ`) |

Let us examine a TCP handshake in the following topology:

_\[Client\] --- (eth1)\[Security Gateway\](eth2) --- \[Server\]_

1. `TCP SYN from [Client] will pass through Pre-Inbound and Post-Inbound on interface eth1:` _\[Client\] --- (eth1) {Pre-Inbound \+ Post-Inbound} \[Security Gateway\](eth2) --- \[Server\]_
2. _TCP **SYN**_ from \[Client\] will pass through _Pre-Outbound_ and _Post-Outbound_ on interface **eth2**:
    _\[Client\] --- (eth1)\[Security Gateway\] {Pre-Outbound and Post-Outbound} (eth2) --- \[Server\]_
3. _TCP **SYN-ACK**_ from \[Server\] will pass through _Pre-Inbound_ and _Post-Inbound_ on interface **eth2**:
    _\[Client\] --- (eth1)\[Security Gateway\] {Pre-Inbound \+ Post-Inbound} (eth2) --- \[Server\]_
4. _TCP **SYN-ACK**_ from \[Server\] will pass through _Pre-Outbound_ and _Post-Outbound_ on interface **eth1**:
    _\[Client\] --- (eth1) {Pre-Outbound and Post-Outbound} \[Security Gateway\](eth2) --- \[Server\]_
5. _TCP **ACK**_ from \[Client\] will pass through _Pre-Inbound_ and _Post-Inbound_ on interface **eth1**:
    _\[Client\] --- (eth1) {Pre-Inbound \+ Post-Inbound} \[Security Gateway\](eth2) --- \[Server\]_
6. _TCP **ACK**_ from \[Client\] will pass through _Pre-Outbound_ and _Post-Outbound_ on interface **eth2**:
    _\[Client\] --- (eth1)\[Security Gateway\] {Pre-Outbound and Post-Outbound} (eth2) --- \[Server\]_

Once started, the _FW Monitor_ compiles the INSPECT filter (created as _$FWDIR/tmp/monitorfilter.pf_) based on the specified syntax (which packets to capture), and loads it to the Check Point kernel (not replacing the Security Policy). The _FW Monitor_ will then continuously get packets from the Check Point kernel, and depending on the syntax, will either display them on the terminal window, or will save them in the output capture file. Upon an interrupt signal (key combination CTRL + C), the _FW Monitor_ stops, unloads the INSPECT filter, and exits.

## (5) FW Monitor Syntax and Usage

### (5-A) FW Monitor Syntax and Usage - Syntax

- For IPv4:

**`[Expert@HostName]# fw monitor [-h] [-u|-s] [-i] [-d] [-D] [-t] [{-e <expr>}+ | -f <filter_file_name>|-] [-l length] [-m i|I|o|O] [-x offset[,length]] [-o <output_file_name>] <[-pi position] [-pI position] [-po position] [-pO position] | -p all> [-a] [-ci count] [-co count] [-v VSID] [-w whole packet] [-F "<src IP>,<src port>,<dst IP>,<dst port>,<protocol num>"] [-U]`**

- For IPv6:

**`[Expert@HostName]# fw6 monitor [-h] [-u|-s] [-i] [-d] [-D] [-t] [{-e <expr>}+ | -f <filter_file_name>|-] [-l length] [-m i|I|o|O] [-x offset[,length]] [-o <output_file_name>] <[-pi position] [-pI position] [-po position] [-pO position] | -p all> [-a] [-ci count] [-co count] [-v VSID] [-w whole packet] [-F "<src IP>,<src port>,<dst IP>,<dst port>,<protocol num>"] [-U]`**

Enter the string to filter this table:

|     |     |
| --- | --- |
| Flag | Explanation |
| `-h` | Displays the usage. |
| `-i` | Flushes the standard output.<br>Use this flag 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`<br>`-D` | Starts the _FW Monitor_ in the debug mode.<br>This will give you an insight into _FW Monitor's_ inner workings, although this option is only rarely used outside Check Point.<br>Use the " _-D_" flag will produce an even more verbose output. |
| `-t` | When compiling the INSPECT filter, includes _$FWDIR/lib/tcpip.def_, which allows using TCP/IP macros.<br> **Warning:** Do not modify anything in _$FWDIR/lib/tcpip.def_ or in any other _$FWDIR/lib/\*.def_ file 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 in SecureKnowldege. |
| `{-e <expr>}+ |<br> -f <filter_file_name> | -` | **Note:** From version [R80.20 Jumbo Jotfix Accumulator take\_73](https://support.checkpoint.com/results/sk/sk137592), the "-e" flag is not supported for Accelerated traffic.<br>Captures only specific packets:<br>- Set the filter expression on the command line using the _-e <expr>_ switch<br>- Read the filter expression from a file using the _-f <filter\_file\_name>_ switch<br>- Read the filter expression from the standard input using the _-f -_ switch<br>**Note:**<br>When using filter expressions on the command line (using " _-e <expr>_" switch), make sure that the expressions are properly quoted.<br>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).<br>Depending on the given operating system and shell, there might be differences between the two forms - especially when using special characters, or (shell) variables in the filter expression. |
| `-l length` | Limits the length of the captured packets. _FW Monitor_ will read only as many bytes from the kernel as specified by the _length_.<br>Make sure to capture as least as many bytes, so that the L3 IP header and L4 Transport header are included. This option allows capturing only the headers of a packet (e.g., IP and TCP), while omitting the actual payload, and thus decreases the size of the output file (by omitting the payload).<br> _FW Monitor_ uses a buffer to transfer the packets from Check Point kernel to user space. If the size of the captured packets is reduced, this buffer will not fill up so fast. |
| `-m i`<br>`-m I`<br>`-m o`<br>`-m O`<br>`-m e`<br>`-m E` | Capture masks. By default, _FW Monitor_ captures packets _before_ and _after_ the FireWall Virtual Machine in both directions.<br>This flag allows to specify the positions (kernel chains), where the traffic should be captured:<br>- `i` \- Pre-Inbound only (before the packet enters a Chain Module in the inbound direction)<br>- `I` \- Post-Inbound only (after the packet passes a Chain Module in the inbound direction) <br>- `o` \- Pre-Outbound only (before the packet enters a Chain Module in the outbound direction)<br>- `O` \- Post-Outbound only (after the packet passes through a Chain Module in the outbound direction)<br>- `e` \- Pre-Outbound VPN only (before the packet enters a VPN Chain Module in the outbound direction)<br>- `E` \- Post-Outbound VPN only (after the packet passes through a VPN Chain Module in the outbound direction) |
| `-x offset[,length]` | Prints packet/payload raw data in addition to the IP and Transport headers. Optionally it is also possible to limit the data written to the screen. |
| `-o <output_file_name>` | Writes the captured raw data into an output file.<br>The format of an output file is the same format used by tools like snoop (refer to [RFC 1761](https://tools.ietf.org/html/rfc1761) for further information). This output file can be later analyzed by tools like WireShark. |
| `-pi position`<br>`-pI position`<br>`-po position`<br>`-pO position`<br>`-p all` | Inserts _FW Monitor_ chain module at a specific position between Check Point kernel chains.<br>In addition to capture masks (which give the ability to specify a specific position), this flag defines where exactly (in Check Point kernel chains) the packets should be captured. |
| `-a` | Uses absolute chain positions (in Check Point kernel chains). This flag changes the chain ID from a relative value (which only makes sense with the matching output from _fw ctl chain_ command) to an absolute value.<br>If the captured data is saved into an output file (using the " _-o <output\_file\_name>_" switch), one of the fields written into the output file would be the chain position of the _FW Monitor_ chain module.<br>Together with a simultaneous execution of " _fw ctl chain_" command you can determine where the packet was captured. Especially when using " _-p all_" switch, you will find the same packet captured multiples times at different chain positions. |
| `-ci count`<br>`-co count` | Captures a specific number of packets.<br>This is especially useful in situations where the FireWall is filtering high amounts of traffic. In such scenarios, _FW Monitor_ may bind so many resources (for writing to the console, or to a file) that recognizing the break sequence (CTRL+C) might take very long time.<br>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 the specified " _count_". |
| `-u | -s` | Prints connection's Universal-Unique-ID (UUID), or connection's Session UUID (SUUID) for every packet.<br>Note that it is only possible to print the UUID or the SUUID - not both. |
| `-v VSID` | Applies only to VSX NG, VSX NGX, and VSX NGX R6x versions.<br>Captures the packets on a specific Virtual Router or Virtual System on VSX Gateway (Example: _fw monitor -v 4 -e "accept;" -o /var/log/fw\_mon.cap_) |
| `-w` | When using the "`-o`" or the "`-x`" flag, there is an option to print the whole raw data of a packet.<br>Supported versions:<br>- R80.40 and above<br>- R80.30 Jumbo Hotfix Accumulator Take 215 and above<br>- R80.20 Jumbo Hotfix Accumulator Take 73 and above |
| `-F "<src IP>, <src port>, <dst IP>, <dst port>, <protocol num>"` | Filtering the packets based on IP / port / protocol. <br>**Notes:**<br>- Value 0 is used as "any".<br>- Up to 5 filters are supported. Multiple filters are applied on packets in OR logical manner.<br>Supported versions:<br>- R80.40 and above<br>- R80.30 Jumbo Hotfix Accumulator Take 215 and above<br>- R80.20 Jumbo Hotfix Accumulator Take 73 and above |
| `-U` | Unloads the FW Monitor filters.<br>Supported versions:<br>- R80.40 and above<br>- R80.30 Jumbo Hotfix Accumulator Take 215 and above<br>- R80.20 Jumbo Hotfix Accumulator Take 73 and above |

### (5-B) FW Monitor Syntax and Usage - Syntax comparison between TCPdump and FW Monitor

Note: Refer to [https://linux.die.net/man/8/tcpdump](https://linux.die.net/man/8/tcpdump).

Enter the string to filter this table:

|     |     |     |     |
| --- | --- | --- | --- |
| Function | Flag in TCPdump | Flag in FW Monitor | Notes |
| Save output into a file | **`-w <output_file_name>`** | **`-o <output_file_name>`** |  |
| Capture specified number<br>of bytes per packet | **`-s snaplen`** | **`-l length`** | For TCPdump:<br>- If not specified, then 65535 bytes are captured<br>- It is recommended to use "`-s 1500`"<br>- Setting _snaplen_ to 0 sets it to the default of 65535 bytes<br>For FW Monitor:<br>- By default, not needed<br>- Refer to the table above |
| Automatically exit after<br>specified number of<br>packets was captured | **`-c count`** | **`-ci count`**<br>**`-co count`** | For FW Monitor:<br>- Refer to the table above |
| Print payload content | **`-X`** | **`-x offset[,length]`** | For TCPdump:<br>- In addition to printing the headers of each packet, prints the data<br>  <br>  of each packet (minus its Link Level header) in Hex and ASCII<br>For FW Monitor:<br>- Refer to the table above |
| Display timestamps on CLI<br>(when not saving<br>output into a file) | **`-tt`** | N/A | For TCPdump:<br>- Prints an unformatted timestamp on each dump line. |
| **`-ttt`** | **`-T`** | For TCPdump:<br>- Prints a delta (micro-second resolution) between<br>  <br>  current and previous line on each dump line. |
| **`-ttt`** | N/A | For TCPdump:<br>- Prints a delta (micro-second resolution) between<br>  <br>  current and previous line on each dump line. |
| **`-tttt`** | N/A | For TCPdump:<br>- Prints a timestamp in default format<br>  <br>  preceeded by date on each dump line. |
| **`-ttttt`** | N/A | For TCPdump:<br>- Print a delta (micro-second resolution) between<br>  <br>  current and first line on each dump line. |
| Display verbose<br>output on CLI<br>(when not saving<br>output into a file) | **`-v`** | **`-d`** | For TCPdump:<br>- Produces slightly more verbose output.<br>  <br>  For example, the TTL, Identification, total length and options<br>  <br>  in an IP packet are printed. Also enables additional packet<br>  <br>  integrity checks, such as verifying the IP and ICMP header checksum.<br>For FW Monitor:<br>- Refer to the table above |
| **`-vv`** | **`-D`** | For TCPdump:<br>- Produces even more verbose output.<br>  <br>  For example, additional fields are printed<br>  <br>  from NFS reply packets, and SMB packets<br>  <br>  are fully decoded.<br>For FW Monitor:<br>- Refer to the table above |
| **`-vvv`** | **`-D`** | For TCPdump:<br>- Produces even more verbose output.<br>  <br>  For example, telnet _SB ... SE_ options<br>  <br>  are printed in full. With "`-X`", Telnet options<br>  <br>  are printed in Hex as well.<br>For FW Monitor:<br>- Refer to the table above |

### (5-C) FW Monitor Syntax and Usage - Using the UUID feature

- **Background**

The purpose of the new FW Monitor feature is to use the UUID feature (that was introduced in the NG AI family) to follow connections passing through the FireWall.

Following connections through the FireWall is not always a trivial task because often the FireWall modifies information in the original packet. These cases include:

- NAT, both Static and Dynamic (Hide)
  - Security Servers
  - VPN Encryption

In Check Point NG AI version, a Universal-Unique-IDentifier (UUID) was introduced as the basis for the log unification mechanism. A UUID is given to every new connection passing through the FireWall. This way, all packets that belong to the connection can be identified and can later be unified on the Security Management Server.

This new infrastructure has given us the ability to enhance the "FW Monitor" utility. The FW Monitor utility is a `tcpdump`/`snoop`-like tool that allows us to monitor packets as they pass through the FireWall. The FW Monitor module registers itself as the first and the last module on the chain, allowing us to see any modifications done by the FireWall on the original packet. With the addition of the UUID field to the FW Monitor, entire connections can be monitored as they pass through the FireWall.

- **The UUID feature**

The original UUID is an array, composed of 4 unsigned 32-bit integers, in which only the first two integers are relevant:

UUID\[0\] is a timestamp.

UUID\[1\] is a counter used whenever UUID\[0\] is not unique.

UUID\[2\] is the IP address of the local firewall (constant)

UUID\[3\] is a process number (currently a constant that can be ignored).

The UUID feature can be activated with one of the following switches:

- **`-u`** = displays the UUID
  - **`-s`** = displays the session UUID, meaning, display a single (parent) UUID of complex connections involving data/control connections (such as FTP, H.323, etc.)

Since we are pressed for space in the header fields of the captured packet, the original UUID has been manipulated to be 1 unsigned long 32-bit integer. It is currently composed of the 2 least significant bytes of UUID\[1\] (16 bits) attached to the 2 least significant bytes of UUID\[0\] (16 bits). This gives us the following amount of unique IDs:

- 216 IDs per second
  - 216 seconds

This UUID is then placed in the last four bytes of the Ethernet MAC Source header field.

The new Ethernet header MAC fields are now:

- 2 bytes - i/I/o/O
  - 6 bytes - Interface Name
  - 4 bytes - UUID

In addition, it is possible to redirect the FW Monitor output to an ASCII file instead of saving it in a `tcpdump`/`snoop` format. If this is the case, the 32-bit manipulated UUID is displayed as the first field of each line, followed by the entire UUID array.

- **Filtering**

When viewing the captured file, it is now possible to view the connection by filtering the file by the UUID. This is done by first opening the captured file, finding a packet that belongs to the connection, and getting the last four bytes of the Source MAC address. Then, convert these four bytes to Decimal format and filter the captured file as follows:

`# tcpdump -r <captured_file_name> -e -v -xx "ether[8:4] = 0xHHHH"`

`# snoop -i <captured_file_name> -v -x0 "ether[8:4] = 0xHHHH"`

where _HHHH_ is the decimal equivalent of the last four bytes of the Source MAC address.

- **Debugging**

The UUID feature can be debugged by collecting the "`fw ctl debug -m fw + chain conn`" debug.

Note: The '`filter`' flag may also provide some information, but produces many irrelevant printouts.
- **Notes**
  - The UUID of the first packet of every new connection before the VM is always 0.
  - The UUID on encrypted packets is also 0.
  - When running the UUID feature and redirecting the output to a captured file, only the first 6 bytes of the interface name will be displayed.
  - The compressed UUID can be similar if taken on two different machines (since the IP address portion of the original UUID was not taken into consideration). In addition, it can also be similar if taken days apart (since the counter portion of the compressed UUID will repeat every 18 hours).

## (6) SecureClient Syntax

- SecurRemote and SecureClient R56 / R60 uses an abridged version of _FW Monitor_ \- called _**srfw monitor**_:

**`%SRDIR%\bin\srfw monitor [-d] [{-e <expr>}+ | -f <filter_file_name> | -] [-l length] [-m i | I | o | O] [-x offset[,length]] [-o <output_file_name>]`**

Refer to _SecureClient R56 for Mac OS X Release Notes_ ( [Mac OS X 10.3](http://downloads.checkpoint.com/dc/download.htm?ID=7970), [Mac OS X 10.4](http://downloads.checkpoint.com/dc/download.htm?ID=7973)) and to [_Debugging SecuRemote/SecureClient_](http://downloads.checkpoint.com/dc/download.htm?ID=10545).

- Starting in E75.30, SecurRemote and SecureClient uses command line packet monitoring utility ( _PacketMon.exe_) \- called _**packetmon**_:

**`packetmon [-d] [-h] [-t] [-T] [-i] [-I] [-r] [{-e <expr>}+ | -f <filter_file_name> | -] [-l length] [-m i | I | o | O] [-x offset[,length]] [-o <output_file_name>] [-ci count] [-co count]`**

Refer to _Remote Access Clients for Windows 32/64-bit Administration Guide_ ( [E75.30](http://downloads.checkpoint.com/dc/download.htm?ID=20401), [E80.41](http://downloads.checkpoint.com/dc/download.htm?ID=23222), [E80.50](http://downloads.checkpoint.com/dc/download.htm?ID=24859)) \- Chapter 'Monitoring and Troubleshooting' - Troubleshooting the Firewall - Desktop Firewall Monitoring.

## (7) Capture Examples of "-e" flag

Refer to the _$FWDIR/lib/fwmonitor.def_ file on the Security Gateway for useful macro definitions.

**Note:** The "`-e`" flag is **not** supported to capture accelerated traffic in these versions:

- R80.40 and above
- R80.30 Jumbo Hotfix Accumulator Take 215 and above
- R80.20 Jumbo Hotfix Accumulator Take 73 and above

### (7-A) Capture Examples - Usual Capture

Capture everything, save the data into the file:

_**\[Expert@HostName\]# fw monitor -e "accept;" -o /var/log/fw\_mon.cap**_

### (7-B) Capture Examples - Host Specific Capture

To specify a host, you can use the following expression:

- Either use " _**host(<IP\_Address\_in\_Doted\_Decimal\_format>)**_", which applies to both Source IP address and Destination IP address

- Or use specific Source IP address " _**src=<IP\_Address\_in\_Doted\_Decimal\_format>**_" and specific Destination IP address " _**dst=<IP\_Address\_in\_Doted\_Decimal\_format>**_"

_Examples_:

- Capture everything between host X and host Y:
_**\[Expert@HostName\]# fw monitor -e "host(x.x.x.x) and host(y.y.y.y), accept;" -o /var/log/fw\_mon.cap**_

_**\[Expert@HostName\]# fw monitor -e "((src=x.x.x.x , dst=y.y.y.y) or (src=y.y.y.y , dst=x.x.x.x)), accept;" -o /var/log/fw\_mon.cap**_
- Capture everything between hosts X,Z and hosts Y,Z on _all_ Check Point kernel chains:
_**\[Expert@HostName\]# fw monitor -p all -e "((src=x.x.x.x or dst=z.z.z.z) and (src=y.y.y.y or dst=z.z.z.z)), accept ;" -o /var/log/fw\_mon.cap**_
- Capture everything to/from host X or to/from host Y or to/from host Z:
_**\[Expert@HostName\]# fw monitor -e "host(x.x.x.x) or host(y.y.y.y) or host(z.z.z.z), accept;" -o /var/log/fw\_mon.cap**_

_**\[Expert@HostName\]# fw monitor -e "((src=x.x.x.x or dst=x.x.x.x) or (src=y.y.y.y or dst=y.y.y.y) or (src=z.z.z.z or dst=z.z.z.z)), accept;" -o /var/log/fw\_mon.cap**_

### (7-C) Capture Examples - Port-Specific Capture

**Note:** Port number in the syntax has to be provided in Decimal format. Refer to _**/etc/services**_ file on the machine, or to [http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml](http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml)

To specify a port, you can use the following expression:

- Either use " _**port(<IANA\_Port\_Number>)**_", which applies to both Source Port and Destination Port

- Or use specific Source Port " _**sport=<IANA\_Port\_Number>**_" and specific Destination Port " _**dport=<IANA\_Port\_Number>**_"

- In addition:
  - For specific _TCP_ port, you can use " _**tcpport(<IANA\_Port\_Number>)**_", which applies to both Source TCP Port and Destination TCP Port
  - For specific _UDP_ port, you can use " _**udpport(<IANA\_Port\_Number>)**_", which applies to both Source UDP Port and Destination UDP Port

_Examples_:

- Capture everything to/from port X:
_**\[Expert@HostName\]# fw monitor -e "port(x), accept;" -o /var/log/fw\_mon.cap**_

_**\[Expert@HostName\]# fw monitor -e "(sport=x or dport=x), accept;" -o /var/log/fw\_mon.cap**_
- Capture everything except port X:
_**\[Expert@HostName\]# fw monitor -e "((sport=!x) or (dport=!x)), accept;" -o /var/log/fw\_mon.cap**_

_**\[Expert@HostName\]# fw monitor -e "not (sport=x or dport=x), accept;" -o /var/log/fw\_mon.cap**_
- Capture everything except SSH:
_**\[Expert@HostName\]# fw monitor -e "((sport!=22) or (dport!=22)), accept;" -o /var/log/fw\_mon.cap**_

_**\[Expert@HostName\]# fw monitor -e "not (sport=22 or dport=22), accept;" -o /var/log/fw\_mon.cap**_

_**\[Expert@HostName\]# fw monitor -e "not tcpport(22), accept;" -o /var/log/fw\_mon.cap**_
- Capture everything to/from host X except SSH:
_**\[Expert@HostName\]# fw monitor -e "(host(x.x.x.x) and (sport!=22 or dport!=22)), accept;" -o /var/log/fw\_mon.cap**_

_**\[Expert@HostName\]# fw monitor -e "((src=x.x.x.x or dst=x.x.x.x) and (not (sport=22 or dport=22))), accept;" -o /var/log/fw\_mon.cap**_

_**\[Expert@HostName\]# fw monitor -e "(host(x.x.x.x) and not tcpport(22)), accept;" -o /var/log/fw\_mon.cap**_
- Capture everything except NTP:
_**\[Expert@HostName\]# fw monitor -e "not udpport(123), accept;" -o /var/log/fw\_mon.cap**_

### (7-D) Capture Examples - Protocol-Specific Capture

**Note:** Protocol number in the expression has to be provided in Decimal format. Refer to _**/etc/protocols**_ file on the machine, or to [http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml](http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml)

To specify a protocol, you can use the following expression:

- Either use " _**ip\_p=<IANA\_Protocol\_Number>**_"

_Examples_:

- To specify TCP protocol with byte offset, use " _**ip\_p=6**_"
  - To specify UDP protocol with byte offset, use " _**ip\_p=11**_"
  - To specify ICMP protocol with byte offset, use " _**ip\_p=1**_"

- Or use " _**accept \[9:1\]=<IANA\_Protocol\_Number>**_"

(This byte offset syntax is described in the "Capture Examples - Bytes Specific Capture" section)

_Examples_:

- To specify TCP protocol with byte offset, use " _**accept \[9:1\]=6**_"
  - To specify UDP protocol with byte offset, use " _**accept \[9:1\]=11**_"
  - To specify ICMP protocol with byte offset, use " _**accept \[9:1\]=1**_"

- In addition, you can explicitly use the following expressions to specify protocols:

|     |     |     |
| --- | --- | --- |
| Which protocol<br>to specify | On which port(s)<br>traffic will<br>be captured | Expression |
| TCP | \-\-\- | _**"tcp, accept;"**_ |
| UDP | \-\-\- | _**"udp, accept;"**_ |
| ICMPv4 | \-\-\- | _**"icmp, accept;"**_<br>or<br>_**"icmp4, accept;"**_ |
| ICMPv6 | \-\-\- | _**"icmp6, accept;"**_ |
| HTTP | TCP 80 | _**"http, accept;"**_ |
| HTTPS | TCP 443 | _**"https, accept;"**_ |
| PROXY | TCP 8080 | _**"proxy, accept;"**_ |
| DNS | UDP 53 | _**"dns, accept;"**_ |
| IKE | UDP 500 | _**"ike, accept;"**_ |
| NAT-T | UDP 4500 | _**"natt, accept;"**_ |
| ESP<br>and<br>IKE | IP proto 50<br>and<br>UDP 500 | _**"vpn, accept;"**_ |
| 01. ESP<br>  02. IPsec over UDP<br>  03. IKE<br>  04. NAT-T<br>  05. CRL<br>  06. RDP<br>  07. Tunnel Test<br>  08. Topology<br>  09. L2TP<br>  10. SCV<br>  11. Multi-Portal<br>  12. etc.<br>This captures _all_<br>VPN-related data. | 01. IP proto 50<br>  02. UDP 2746<br>  03. UDP 500<br>  04. UDP 4500<br>  05. TCP 18264<br>  06. UDP 259<br>  07. UDP 18234<br>  08. TCP 264<br>  09. TCP 1701<br>  10. UDP 18233<br>  11. TCP 443 + TCP 444<br>  12. etc. | _**"vpnall, accept;"**_ |
| Multi-Portal<br>connections | TCP 443<br>and<br>TCP 444 | _**"multi, accept;"**_ |
| SSH | TCP 22 | _**"ssh, accept;"**_ |
| FTP | TCP 20<br>and<br>TCP 21 | _**"ftp, accept;"**_ |
| Telnet | TCP 23 | _**"telnet, accept;"**_ |
| SMTP | TCP 25 | _**"smtp, accept;"**_ |
| POP3 | TCP 110 | _**"pop3, accept;"**_ |

_Examples_:

- Capture everything on protocol X:
_**\[Expert@HostName\]# fw monitor -e "ip\_p=X, accept;" -o /var/log/fw\_mon.cap**_
- Everything on protocol X and port Z on protocol Y:
_**\[Expert@HostName\]# fw monitor -e "(ip\_p=X) or (ip\_p=Y, port(Z)), accept;" -o /var/log/fw\_mon.cap**_
- Capture everything TCP between host X and host Y:
_**\[Expert@HostName\]# fw monitor -e "ip\_p=6, host(x.x.x.x) or host(y.y.y.y), accept;" -o /var/log/fw\_mon.cap**_

_**\[Expert@HostName\]# fw monitor -e "tcp, host(x.x.x.x) or host(y.y.y.y), accept;" -o /var/log/fw\_mon.cap**_

_**\[Expert@HostName\]# fw monitor -e "accept \[9:1\]=6 , ((src=x.x.x.x , dst=y.y.y.y) or (src=y.y.y.y , dst=x.x.x.x));"**_

_**\[Expert@HostName\]# fw monitor -e "ip\_p=6, ((src=x.x.x.x , dst=y.y.y.y) or (src=y.y.y.y , dst=x.x.x.x)), accept;" -o /var/log/fw\_mon.cap**_

### (7-E) Capture Examples - Protocol Options Specific Capture

**Note:** Refer to the _$FWDIR/lib/tcpip.def_ file on the Security Gateway.

|     |     |     |
| --- | --- | --- |
| Protocol | Expression | Option Description |
| [IPv4](http://en.wikipedia.org/wiki/IPv4) | _**ip\_src = <IPv4\_Address>**_ | Source [IPv4 address](https://en.wikipedia.org/wiki/IPv4_address) of the [IPv4 packet](https://en.wikipedia.org/wiki/IPv4#Header)<br>Example:<br>_fw monitor -e "ip\_src = 192.168.22.33, accept;"_ |
| _**ip\_dst = <IPv4\_Address>**_ | Destination [IPv4 address](https://en.wikipedia.org/wiki/IPv4_address) of the [IPv4 packet](https://en.wikipedia.org/wiki/IPv4#Header)<br>Example:<br>_fw monitor -e "ip\_dst = 192.168.22.33, accept;"_ |
| _**ip\_ttl = <Number>**_ | [Time To Live](https://en.wikipedia.org/wiki/Time_to_live) of the [IPv4 packet](https://en.wikipedia.org/wiki/IPv4#Header)<br>Example:<br>_fw monitor -e "ip\_ttl = 255, accept;"_ |
| _**ip\_len = <Length\_in\_Bytes>**_ | Total Length of the [IPv4 packet](https://en.wikipedia.org/wiki/IPv4#Header) in bytes<br>Example:<br>_fw monitor -e "ip\_len = 64, accept;"_ |
| _**ip\_tos = <Number>**_ | [TOS field](https://en.wikipedia.org/wiki/Type_of_service) of the [IPv4 packet](https://en.wikipedia.org/wiki/IPv4#Header)<br>Example:<br>_fw monitor -e "ip\_tos = 0, accept;"_ |
| _**ip\_p = <IANA\_Protocol\_Number>**_ | [IANA Protocol Number](http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml) (either in Dec or in Hex) encapsulated in the [IPv4 packet](https://en.wikipedia.org/wiki/IPv4#Header)<br>Example 1 for TCP:<br>_fw monitor -e "ip\_p = 6, accept;"_<br>Example 2 for UDP:<br>_fw monitor -e "ip\_p = 17, accept;"_<br>Example 3 for UDP:<br>_fw monitor -e "ip\_p = 0x11, accept;"_<br>Example 4 for ICMP:<br>_fw monitor -e "ip\_p = 1, accept;"_ |
| [IPv6](http://en.wikipedia.org/wiki/IPv6) | _**ip\_src6p = <IPv6\_Address>**_ | Source [IPv6 address](https://en.wikipedia.org/wiki/IPv6_address) of the [IPv6 packet](https://en.wikipedia.org/wiki/IPv6_packet#Fixed_header) |
| _**ip\_dst6p = <IPv6\_Address>**_ | Destination [IPv6 address](https://en.wikipedia.org/wiki/IPv6_address) of the [IPv6 packet](https://en.wikipedia.org/wiki/IPv6_packet#Fixed_header) |
| _**ip\_len6 = <Length\_in\_Bytes>**_ | Payload Length of the [IPv6 packet](https://en.wikipedia.org/wiki/IPv6_packet#Fixed_header) in bytes |
| _**ip\_ttl6 = <Number>**_ | Hop Limit ("Time To Live") of the [IPv6 packet](https://en.wikipedia.org/wiki/IPv6_packet#Fixed_header) |
| _**ip\_p6 = <IANA\_Protocol\_Number>**_ | Next Header of the [IPv6 packet](https://en.wikipedia.org/wiki/IPv6_packet#Fixed_header) \- encapsulated [IANA Protocol Number](http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml)<br>Example: _fw monitor -e "ip\_p6 = 6, accept;"_ |
| [TCP](http://en.wikipedia.org/wiki/Transmission_Control_Protocol) | _**syn**_ | SYN flag is set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure)<br>Example:<br>_fw monitor -e "ip\_p = 6, syn, accept;"_ |
| _**ack**_ | ACK flag is set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure)<br>Example:<br>_fw monitor -e "ip\_p = 6, ack, accept;"_ |
| _**rst**_ | RST flag is set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure)<br>Example:<br>_fw monitor -e "ip\_p = 6, rst, accept;"_ |
| _**fin**_ | FIN flag is set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure)<br>Example:<br>_fw monitor -e "ip\_p = 6, fin, accept;"_ |
| _**first**_ | First packet of TCP connection<br>(i.e., SYN flag is set, but ACK flag is _not_ set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure))<br>Example:<br>_fw monitor -e "ip\_p = 6, first, accept;"_ |
| _**not\_first**_ | Not the first packet of TCP connection<br>(i.e., SYN flag is _not_ set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure))<br>Example: _fw monitor -e "ip\_p = 6, not\_first, accept;"_ |
| _**established**_ | Established TCP connection<br>(i.e., either ACK flag is set, _or_ SYN flag is _not_ set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure))<br>Example:<br>_fw monitor -e "ip\_p = 6, established, accept;"_ |
| _**last**_ | Last packet of TCP connection<br>(i.e., both ACK flag _and_ FIN flag are set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure))<br>Example:<br>_fw monitor -e "ip\_p = 6, last, accept;"_ |
| _**tcpdone**_ | End of TCP connection<br>(i.e., either RST flag is set, _or_ FIN flag is set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure))<br>Example:<br>_fw monitor -e "ip\_p = 6, tcpdone, accept;"_ |
| _**th\_flags = <Sum\_of\_Flags\_Hex\_Values>**_ | General way to match the flags inside in [TCP packets](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure):

|     |     |     |
| --- | --- | --- |
| Syntax | Explanation | Example |
| _th\_flags = 0x2_ | SYN flag is set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure) | _fw monitor -e "th\_flags = 0x2, accept;"_ |
| _th\_flags = 0x10_ | ACK flag is set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure) | _fw monitor -e "th\_flags = 0x10, accept;"_ |
| _th\_flags = 0x8_ | PSH flag is set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure) | _fw monitor -e "th\_flags = 0x8, accept;"_ |
| _th\_flags = 0x1_ | FIN flag is set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure) | _fw monitor -e "th\_flags = 0x1, accept;"_ |
| _th\_flags = 0x4_ | RST flag is set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure) | _fw monitor -e "th\_flags = 0x4, accept;"_ |
| _th\_flags = 0x20_ | URG flag is set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure) | _fw monitor -e "th\_flags = 0x20, accept;"_ |
| _th\_flags = 0x12_ | SYN flag (0x2) _and_ ACK flag (0x10) are set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure) | _fw monitor -e "th\_flags = 0x12, accept;"_ |
| _th\_flags = 0x18_ | PSH flag (0x8) _and_ ACK flag (0x10) are set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure) | _fw monitor -e "th\_flags = 0x18, accept;"_ |
| _th\_flags = 0x11_ | FIN flag (0x1) _and_ ACK flag (0x10) are set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure) | _fw monitor -e "th\_flags = 0x11, accept;"_ |
| _th\_flags = 0x14_ | RST flag (0x4) _and_ ACK flag (0x10) are set in [TCP packet](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure) | _fw monitor -e "th\_flags = 0x14, accept;"_ | |
| _**th\_sport = <Port\_Number>**_ | TCP source port (refer to [IANA Port Number Registry](http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml))<br>Example:<br>_fw monitor -e "th\_sport = 59259, accept;"_ |
| _**th\_dport = <Port\_Number>**_ | TCP destination port (refer to [IANA Port Number Registry](http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml))<br>Example:<br>_fw monitor -e "th\_dport = 22, accept;"_ |
| _**th\_seq = <Number>**_ | TCP sequence number (either in Dec or in Hex)<br>Example 1:<br>_fw monitor -e "th\_seq = 3937833514, accept;"_<br>Example 2:<br>_fw monitor -e "th\_seq = 0xeab6922a, accept;"_ |
| _**th\_ack = <Number>**_ | TCP acknowledged number (either in Dec or in Hex)<br>Example 1:<br>_fw monitor -e "th\_ack = 509054325, accept;"_<br>Example 2:<br>_fw monitor -e "th\_ack = 0x1e578d75, accept;"_ |
| [UDP](http://en.wikipedia.org/wiki/User_Datagram_Protocol) | _**uh\_sport = <Port\_Number>**_ | UDP source port (refer to [IANA Port Number Registry](http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml))<br>Example:<br>_fw monitor -e "uh\_sport = 8116, accept;"_ |
| _**uh\_dport = <Port\_Number>**_ | UDP destination port (refer to [IANA Port Number Registry](http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml))<br>Example:<br>_fw monitor -e "uh\_dport = 53, accept;"_ |
| [ICMPv4](http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol) | _**icmp\_type = <Number>**_ | [ICMPv4 packets](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#ICMP_segment_structure) with specified [Type](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Control_messages)<br>Example:<br>_fw monitor -e "icmp\_type = 0, accept;"_ |
| _**icmp\_code = <Number>**_ | [ICMPv4 packets](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#ICMP_segment_structure) with specified [Code](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Control_messages)<br>Example:<br>_fw monitor -e "icmp\_code = 0, accept;"_ |
| _**icmp\_id = <Number>**_ | [ICMPv4 packets](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#ICMP_segment_structure) with specified Identifier<br>Example:<br>_fw monitor -e "icmp\_id = 20583, accept;"_ |
| _**icmp\_seq = <Number>**_ | [ICMPv4 packets](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#ICMP_segment_structure) with specified Sequence number<br>Example:<br>_fw monitor -e "icmp\_seq = 1, accept;"_ |
| _**echo\_req**_ | [ICMPv4](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#ICMP_segment_structure) [Echo Request](https://en.wikipedia.org/wiki/Ping_(networking_utility)) packets (Type 8, Code 0)<br>Example:<br>_fw monitor -e "echo\_req, accept;"_ |
| _**echo\_reply**_ | [ICMPv4](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#ICMP_segment_structure) [Echo Reply](https://en.wikipedia.org/wiki/Ping_(networking_utility)) packets (Type 0, Code 0)<br>Example:<br>_fw monitor -e "echo\_reply, accept;"_ |
| _**ping**_ | [ICMPv4](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#ICMP_segment_structure) [Echo Request _and_ ICMPv4 Echo Reply](https://en.wikipedia.org/wiki/Ping_(networking_utility)) packets<br>Example:<br>_fw monitor -e "ping, accept;"_ |
| _**traceroute**_ | [Traceroute](https://en.wikipedia.org/wiki/Traceroute) packets as implemented in Unix OS (UDP packets on ports 30000 and greater and with TTL<30; or ICMP Time exceeded packets)<br>Example:<br>_fw monitor -e "traceroute, accept;"_ |
| _**tracert**_ | [Traceroute](https://en.wikipedia.org/wiki/Traceroute) packets as implemented in Windows OS (ICMP Request packets with TTL<30; or ICMP Time exceeded packets)<br>Example:<br>_fw monitor -e "tracert, accept;"_ |
| _**icmp\_ip\_len = <length>**_ | Length of [ICMPv4 packets](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#ICMP_segment_structure)<br>Example:<br>_fw monitor -e "icmp\_ip\_len = 84, accept;"_ |
| [ICMPv6](http://en.wikipedia.org/wiki/ICMPv6) | _**icmp6\_type = <Number>**_ | [ICMPv6 packets](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol_version_6#Packet_format) with specified [Type](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol_version_6#Types_of_ICMPv6_messages)<br>Example:<br>_fw monitor -e "icmp6\_type = 1, accept;"_ |
| _**icmp6\_code = <Number>**_ | [ICMPv6 packets](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol_version_6#Packet_format) with specified [Code](https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol_version_6#Types_of_ICMPv6_messages)<br>Example:<br>_fw monitor -e "icmp6\_code = 3, accept;"_ |

### (7-F) Capture Examples - Byte-Specific Capture

Simple checks are used to check for a value at a specific offset in the packet:

_**\[Expert@HostName\]# fw monitor -e "accept \[ offset : length , order \] relational-operator value;"**_

|     |     |
| --- | --- |
| Field | Explanation |
| `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:<br>- 1 = byte<br>- 2 = word<br>- 4 = dword<br>If length is _not_ specified, _FW Monitor_ assumes 4 (dword). |
| `order` | Specifies the byte order:<br>- `b` = big-endian, or network order<br>- `l` = little-endian, or host order<br>If order is not specified, _FW Monitor_ assumes little endian byte order. |
| `relational-operator` | Relational operator to express the relation between the packet data and the value:

|     |     |
| --- | --- |
| _<_ | less than |
| _>_ | greater than |
| _<=_ | less than or equal to |
| _>=_ | greater than |
| _=_ | equal to |
| _is_ |
| _!=_ | not equal to |
| _is not_ | |
| `value` | One of the data types known to INSPECT (e.g., an IP address, or an integer). |

The IP-based protocols are stored in the IP packet as a byte at offset 9:

- To filter based on a Protocol encapsulated into IP, use this syntax:
_**\[Expert@HostName\]# fw monitor -e "accept \[9:1\]=<IANA\_Protocol\_Number>;"**_

The Layer 3 IP Addresses are stored in the IP packet as double words at offset 12 (Source address) and at offset 16 (Destination address):

- To filter based on a Source IP address, use this syntax:
_**\[Expert@HostName\]# fw monitor -e "accept \[12:4,b\]=<IP\_Address\_in\_Doted\_Decimal\_format>;"**_
- To filter based on a Destination IP address, use this syntax:
_**\[Expert@HostName\]# fw monitor -e "accept \[16:4,b\]=<IP\_Address\_in\_Doted\_Decimal\_format>;"**_

The Layer 4 Ports are stored in the IP packet as a word at offset 20 (Source port) and at offset 22 (Destination port):

- To filter based on a Source port, use this syntax:
_**\[Expert@HostName\]# fw monitor -e "accept \[20:2,b\]=<Port\_Number\_in\_Decimal\_format>;"**_
- To filter based on a Destination port, use this syntax:
_**\[Expert@HostName\]# fw monitor -e "accept \[22:2,b\]=<Port\_Number\_in\_Decimal\_format>;"**_

_Examples_:

- Capture everything between host X and host Y:
_**\[Expert@HostName\]# fw monitor -e "accept ((\[12:4,b\]=x.x.x.x , \[16:4,b\]=y.y.y.y) or (\[12:4,b\]=y.y.y.y , \[16:4,b\]=x.x.x.x));"**_
- Capture everything on port X:
_**\[Expert@HostName\]# fw monitor -e "accept \[20:2,b\]=x or \[22:2,b\]=x;" -o /var/log/fw\_mon.cap**_

### (7-G) Capture Examples - Network-Specific Capture

To capture traffic to/from a network, you need to specify the _**network address**_ and _**length of network mask**_ (number of bits).

There are 3 options:

|     |     |
| --- | --- |
| Traffic direction | Expression |
| To or From a network | _**"net(<Network\_IP\_Address>, <Mask\_Length>), accept;"**_ |
| To a network | _**"to\_net(<Network\_IP\_Address>, <Mask\_Length>), accept;"**_ |
| From a network | _**"from\_net(<Network\_IP\_Address>, <Mask\_Length>), accept;"**_ |

_Examples_:

- Capture everything to/from network 192.168.33.0 / 24:
_**\[Expert@HostName\]# fw monitor -e "net(192.168.33.0, 24), accept;"**_
- Capture everything sent to network 192.168.33.0 / 24:
_**\[Expert@HostName\]# fw monitor -e "to\_net(192.168.33.0, 24), accept;"**_
- Capture everything sent from network 192.168.33.0 / 24:
_**\[Expert@HostName\]# fw monitor -e "from\_net(192.168.33.0, 24), accept;"**_

### (7-H) Capture Examples - Some Examples

- Capture ESP protocol or UDP port 161 (SNMP):
_**\[Expert@HostName\]# fw monitor -e "(ip\_p=50) or (ip\_p=17, port(161)), accept;" -o /var/log/fw\_mon.cap > /dev/null 2>&1 &**_
- Filter out the usual garbage (SMTP, POP3, SSH, Microsoft NetBIOS, Check Point ClusterXL CCP):
_**\[Expert@HostName\]# fw monitor -e "(sport!=25) and (dport!=25) and (sport!=110) and (dport!=110) and (sport!=22) and (dport!=22) and (sport!=137) and (dport!=137) and (sport!=8116) and (dport!=8116), accept;" -o /var/log/fw\_mon.cap > /dev/null 2>&1 &**_
- Filter out the usual garbage (filter in only TCP protocol, and HTTP and HTTPS ports ; filter out the SSH and FW Logs):
_**\[Expert@HostName\]# fw monitor -e "accept (ip\_p=6) and (not (sport=22 or dport=22)) and (not (sport=257 or dport=257)) and ((dport=80 or dport=443) or (sport=80 or sport=443);" -o /var/log/fw\_mon.cap > /dev/null 2>&1 &**_
- Capture Edge communication between 10.10.10.10, or 20.20.20.20, or 30.30.30.30 and on UDP ports 9281, or 9282, or 9283:
_**\[Expert@HostName\]# fw monitor -e "ip\_p=17, (host(10.10.10.10) or host(20.20.20.20) or host(30.30.30.30)) and (port(9281) or port(9282) or port(9283)), accept;" -o /var/log/fw\_mon.cap**_

## (8) Capture Examples of "-F" flag

### (8-A) Usual Capture

Capture everything, you can use the following expression:

**_-F "0,0,0,0,0"_**

### (8-B) Host-Specific Capture

To specify a host, you can use the following expression:

**_-F "x.x.x.x,0,y.y.y.y,0,0"_**

This will filter for connections with the source IP x.x.x.x and the destination IP y.y.y.y.

Protocol number and port numbers can be any value.

**Note:** This means the filter will only catch one direction of the connection, so set a second (set of) filter to catch the other direction.

Examples:

- **_fw monitor -F "x.x.x.x,0,y.y.y.y,0,0"_**

This will filter connection "x.x.x.x:<Any> --> y.y.y.y:<Any>, <protocol: Any>"

Source ip: x.x.x.x, source port: any, destination ip: y.y.y.y, destination port: any, protocol: any.

- **_fw monitor -F "x.x.x.x,0,y.y.y.y,0,0" -F "y.y.y.y,0,x.x.x.x ,0,0"_**

This will filter connection "x.x.x.x:<Any> --> y.y.y.y:<Any>, <protocol: Any>" or connection " y.y.y.y:<Any> --> x.x.x.x:<Any>, <protocol: Any>"

Filter 1: source ip: x.x.x.x, source port: any, destination ip: y.y.y.y, destination port: any, protocol: any.

Filter 2: source ip: y.y.y.y, source port: any, destination ip: x.x.x.x, destination port: any, protocol: any.

### (8-C) Port-Specific Capture

To specify ports numbers, you can use the following expression:

**_-F "0,x,0,y,0"_**

This will filter connection with source port x and destination port y. Protocol number and ip's can be any value.

Examples:

- **_fw monitor -F "0,x,0,y,0"_**

This will filter connection "<Any>:x --><Any>:y, <protocol: Any>"

Source ip: any, source port: x, destination ip: any, destination port: y, protocol: any.

- **_fw monitor -F "x.x.x.x,z,y.y.y.y,0,0" -F "y.y.y.y,0, x.x.x.x ,z ,0"_**

This will filter connection "x.x.x.x:z --> y.y.y.y:<Any>, <protocol: Any>" or connection " y.y.y.y:<Any> --> x.x.x.x:z, <protocol: Any>"

Filter 1: source ip: x.x.x.x, source port: z, destination ip: y.y.y.y, destination port: any, protocol: any.

Filter 2: source ip: y.y.y.y, source port: any, destination ip: x.x.x.x, destination port: z, protocol: any.

### (8-D) Protocol-Specific Capture

To specify a protocol number, you can use the following expression:

**_-F "0,0,0,0,x"_**

This will filter for connections with the protocol number "X".

Port number and IP addresses can be any value.

Examples:

- **_fw monitor -F "0,0,0,0,x"_**

This will filter connection "<Any>:<Any> --> <Any>:<Any>, <protocol: x>"

Source ip: any, source port: any, destination ip: any, destination port: any, protocol: x.

For example, to capture the GRE traffic (protocol 47): _fw monitor -F "0,0,0,0,47"_

- **_fw monitor -F "x.x.x.x,0,y.y.y.y,z,m" -F "y.y.y.y,z, x.x.x.x ,0,m"_**

This will filter connection "x.x.x.x:<Any> --> y.y.y.y:z, <protocol: m>" or connection " y.y.y.y:z --> x.x.x.x:<Any>, <protocol: m>"

Filter 1: source ip: x.x.x.x, source port: any, destination ip: y.y.y.y, destination port: z, protocol: m.

Filter 2: source ip: y.y.y.y, source port: z, destination ip: x.x.x.x, destination port: any, protocol: m.

## (9) Related Documentation

- [Security Gateway Guide](https://support.checkpoint.com/product/73#f-commonsource=C.%20Documentation)

## (10) Related Solutions

- [sk101878 - CPView Utility](https://support.checkpoint.com/results/sk/sk101878)

- [sk141412 - cppcap - A Check Point Traffic Capture Tooly](https://support.checkpoint.com/results/sk/sk141412)

- [sk43076 - How to work with large traffic capture files](https://support.checkpoint.com/results/sk/sk43076)

- [sk39510 - How to configure Wireshark to show Check Point FireWall chains in an FW Monitor packet](https://support.checkpoint.com/results/sk/sk39510)

- [sk52421 - Ports used by Check Point software](https://support.checkpoint.com/results/sk/sk52421)

#### NOTE

This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.

## Article Properties

Access LevelGeneral

StatusApproved by TAC

Date Created2005-03-02

Last Modified2026-02-15

Was this page helpful?YesNo

#### Haven't found what you're looking for?

##### Our customer support team is only a click away and ready to help you 24 hours a day.

[Open a Service Request](https://help.checkpoint.com/s/case-creation?visitorId=null)

reCAPTCHA

Recaptcha requires verification.

protected by **reCAPTCHA**