Chapter

General Troubleshooting 1
A common part of a Security Administrator’s responsibilities is troubleshooting net-
work problems and using basic troubleshooting techniques to resolve VPN-1 issues.
Troubleshooting guidelines are provided in this chapter to assist the Security Admin-
istrator in defining a problem, identifying possible causes, narrowing causes to one or
a few causes, and finding and testing problem fixes.

Objectives:

Describe general troubleshooting guidelines used to resolve VPN-1 NGX

problems.
Given your understanding of IP forwarding and routing, troubleshoot common
network connectivity problems in a new implementation of VPN-1 NGX.
Use NGX command-line tools to monitor the default filter and initial policy’s
effect on traffic through a Security Gateway
Given the general troubleshooting guidelines, troubleshoot Secure Internal
Communication (SIC) and Network Address Translation (NAT) issues.

19
Chapter 1: General Troubleshooting

Key Terms:

IP forwarding
Default Filter
Initial Policy
Secure Internal Communication (SIC)
Network Address Translation (NAT)
Source NAT
Destination NAT
Client-side NAT
Core file
Securecopy (SCP)

20 Check Point Security Administration NGX III

Troubleshooting Guidelines Chapter 1: General Troubleshooting

Troubleshooting Guidelines
The variety, flexibility, and complexity of the Check Point product suite
can make every problem seem unique. Despite the challenges inherent in
maintaining and administering rapidly evolving security and connectivity
solutions, standard troubleshooting methods are still relevant. Apply the
guidelines in this section when troubleshooting NGX issues.

Identifying the Problem

Identifying a problem should begin with these general questions:
Which outcome is specifically desired, but is not happening?
What is happening, in observable and objective terms?

VPN Example
For example, a remote user is at a hotel trying to connect to the Security
Gateway through SecureClient, and it fails to communicate with the site.
When the remote user is at home the connection works fine, and no
other users are affected. There are no logs in SmartView Tracker for this
connection.
Using the two questions previously stated, you can:
Determine the desired activity: SecureClient PC connects to the
Security Gateway and creates a VPN tunnel. This does not occur for a
particular user.
Determine what is happening, in observable and objective terms: The
Client attempts a connection but there is no response from the
Gateway. SmartView Tracker shows no logs for this user.

Collecting Related Information

Check Point Security Administration NGX III 21

Chapter 1: General Troubleshooting Listing Possible Causes

Once an expected behavior has been identified as a problem, collect

related information by answering the following questions:
Under what circumstances does this problem occur?
What changed before the problem occurred?
Collect log messages, error messages, core files, Dr. Watson output,
packet captures and any relevant information from related
documentation. Verify the configuration of components displaying the
same symptoms.
In the VPN example, the problem only occurs when the Client is at the
hotel. The user does not have a problem when connecting from home.
No other users are reporting a problem. The problem started when the
user tried to connect from the hotel.

Listing Possible Causes

Using the information gathered from symptoms and documentation, try
to find as many potential causes for each symptom. Put the most likely
cause first on a list, and organize the others in order of most likely to
least likely. For our vpn example here are several possible causes:
Port 500 is being blocked on a router upstream from the client
The client is failing SCV checking and is getting blocked by the
Security Gateway
The client has network connectivity problems and is not
attempting a connection
The client is dropping the connection.

Testing Causes Individually and Logically

The goal is to narrow the list to a few causes, starting from the most
likely to the least likely causes. From the VPN example, a srfw monitor
shows that main mode packets are leaving the Client. SmartView
Tracker does not show main mode packets from the Client. A fw

22 Check Point Security Administration NGX III

Consulting Various Reference Sources Chapter 1: General Troubleshooting

monitor on the Security Gateway shows no traffic for the Client. From
this information we assume that main mode traffic from the Client is
being blocked on a router upstream from the Client. The user edits the
Advanced Properties and checks Visitor Mode. After enabling visitor
mode, which works on port 443 instead of 500, the connection succeeds.

Consulting Various Reference Sources

Release notes, Web sites, mailing lists, SecureKnowledge, and Check
Point Technical Support are common reference sources. Visit Check
Point’s Web site for these sources: www.checkpoint.com

Check Point Security Administration NGX III 23

Chapter 1: General Troubleshooting Before Installing VPN-1 NGX

Before Installing VPN-1 NGX

In general, a machine intended as a Security Gateway must function as a
Gateway at the OS level before VPN-1 NGX is installed. The Gateway
must route among network interfaces. If routing does not work before
installing VPN-1 NGX, the machine will not function as a Security
Gateway.
Verify routing on the Gateway system at the OS level. If VPN-1 NGX is
already installed on the Gateway, stop the firewall services. Stopping the
firewall services will disable IP forwarding and the Security Policy. To
test connectivity, enabled IP forwarding.

IP Forwarding
IP forwarding is the operating system’s ability to forward packets from
one interface to another. The default behavior prior to the VPN-1
installation may vary depending on the OS. By default, SecurePlatform
disables IP forwarding during boot and while the default filter is loaded
to protect the Security Gateway during installation. Once the firewall
services are started and a policy is installed from the SmartCenter
Server, IP forwarding is enabled. When the firewall services are stopped,
IP forwarding is disabled. You can manually enable IP forwarding for
testing.
Enabling/Disabling IP Forwarding

Solaris
Enable IP forwarding on Solaris by running ndd:
ndd -set /dev/IP ip_forwarding 1

To disable IP forwarding, run ndd:

ndd -set /dev/IP ip_forwarding 0

To verify the status of IP forwarding:

ndd -get /dev/IP ip_forwarding

24 Check Point Security Administration NGX III

Routing Chapter 1: General Troubleshooting

SecurePlatform
Verify the IP forwarding setting on SecurePlatform and
SecurePlatform Pro, by checking the value in the ip_forward file:
more /proc/sys/net/ipv4/ip_forward

The output should be 1. If the value is 0, run the following command

to enable IP forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward

Windows
Enable IP forwarding on Windows 2000 Server or Windows 2003
Server, check the value of the key IPEnableRouter in the Registry.
Enabling the Remote Access Server (RAS) service can also be used to
enable IP forwarding. The value should be 1. The path to the Registry
key is:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpi
p\parameters\IPEnableRouter

Routing
As a multihomed host, an NGX Gateway has routes automatically
generated for its immediate networks, (external and internal). The
Gateway can only have one default Gateway (or default route) pointing
to its upstream router. If there is more than one internal network
connecting to an internal router behind the Gateway, add static routes
on the Gateway to reach the remote internal networks from the
Gateway.

A NGX Security Gateway supports multiple external interfaces, but

only one default Gateway is allowed.

Check Point Security Administration NGX III 25

Chapter 1: General Troubleshooting Connectivity

For the immediate internal network, it is sufficient to point the default

Gateway of each internal network’s machine to the IP address of the
internal interface of the NGX Gateway.

Before installing an NGX Gateway, one interface on the machine must

be up and running.

Connectivity
To test connectivity with the NGX Gateway in place, ping through the
Gateway from internal nodes to nodes on the external side of the
Gateway, or Ping to the upstream router. Run a ping test as follows:
1. Run fw unloadlocal on the Gateway.

In NGX, the fw unloadlocal command disables IP forwarding.

Enable IP forwarding in order to route through the Security Gateway.

2. Ping from the internal host to the Gateway’s internal interface.

3. Ping to the Gateway’s external interface.
4. Ping a known Internet site address or name (for example,
www.yahoo.com). The Security Gateway must have a DNS server
defined.
5. If the Ping can only reach the external interface of the Gateway, Ping
from the Gateway to a known Internet site.

When using RFC defined addresses for internal networks, ping test
replies from the Internet will not be received by the internal hosts.

6. If you can Ping from the Gateway to the Internet, but cannot reach
the Internet from an internal network, IP forwarding may not be
enabled on the Gateway’s OS.

26 Check Point Security Administration NGX III

Connectivity Chapter 1: General Troubleshooting

7. If you can ping all the way through, install a simple Rule Base with
necessary rules (for example, outbound HTTP), then browse known
Internet sites.

To resolve FQDN names, internal hosts must have a DNS server, either
on an internal network or hosted by an ISP on the Internet. Domain
Name Service over UDP must be allowed.

Check Point Security Administration NGX III 27

Chapter 1: General Troubleshooting IP forwarding and Boot Security

IP forwarding and Boot Security

When a Security Gateway boots after installation, a default filter is
loaded and IP forwarding is disabled until VPN-1 services start. There
are five default filters. The general default filter blocks all inbound
traffic to the Gateway and is the default option. The drop default filter
allows no inbound or outbound communication. The other three filters
are IPSO specific (Nokia Security Gateway) and include inbound SSH
only, inbound HTTPS only or inbound SSH and HTTPS for Remote
Administration.

Check Point strongly recommends starting VPN-1 NGX automatically

on reboot.

The default filter can be changed to the drop filter to block all
communication into and out of the Security Gateway during boot. This
is done by using the fw defaultgen command.
1. These two filters are located in $FWDIR/lib/
a defaultfilter.boot - general default filter
b defaultfilter.drop - drop default filter
2. Copy over and rename the relevant desired Default Filter Inspect file
(defaultfilter.boot or defaultfilter.drop) to $FWDIR/conf/
defaultfilter.pf.
3. Compile the default filter by running:
fw defaultgen

The output will be in $FWDIR/state/default.bin

4. Run fwboot bootconf get_def to print the default filter file path.
5. Copy default.bin to the default filter file path.

28 Check Point Security Administration NGX III

IP forwarding and Boot Security Chapter 1: General Troubleshooting

If the Security Policy has not yet been installed, run cpconfig to
regenerate the Initial Policy.

Q.) One internal host behind an NGX Gateway cannot connect to the
Internet. This host has just been added to the internal network. All other
hosts from the same network segment can connect to the Internet. In the
Rule Base, there is a rule accepting outbound HTTP traffic for the
entire network, and the rule is tracked as Log. When you open
SmartView Tracker, you find no logs from that problematic host. What
is the next reasonable step for troubleshooting this problem?
A.) Check the routing table on that host, and make sure the default-
Gateway setting is correct. Test connectivity, using ping or traceroute,
from the host to the Gateway, or beyond.
Q.) You find a log indicating HTTP is accepted, the source is that host,
and the rule number is correct. But the host’s browser displays “page
cannot be displayed”. What is the next reasonable step for
troubleshooting this problem?
A.) Run fw monitor, to see if the reply packet returns to the Gateway’s
external interface.

Once the VPN-1 services start, the default filter is replaced by the
Initial Policy. The Initial Policy allows SmartConsole to connect to a
SmartCenter Server, but still blocks all other traffic to the Gateway. The
Initial Policy is enforced on the Gateway until a policy is installed from
the SmartCenter Server. Once a policy is installed, the Initial Policy is
never loaded again.

Check Point Security Administration NGX III 29

Chapter 1: General Troubleshooting IP forwarding and Boot Security

When the SIC activation key is reset through cpconfig on the Security
Gateway, the default filter is loaded until SIC is re-established with the
SmartCenter Server and a policy is installed.

You can verify whether the Initial Policy is installed by running fw stat
from the Gateway’s Command Line Interface (CLI). To remove the
Initial Policy, run fw unloadlocal on the Gateway. When a Policy is
unloaded from a Gateway, the Gateway is vulnerable, it accepts anything
that is coming to it, like a router without any ACLs. An Administrator
should limit the amount of time a Policy is unloaded from the Gateway.

Q.) You discover no traffic is passing through the NGX Gateway. You
cannot open SmartConsole or SmartView Tracker. You cannot log in to
the Gateway in SSH from the internal or external network. What is the
next troubleshooting step to take?
A.) Unload the Policy, using fw unloadlocal from the console.
Q.) After you log in to the console, you find out IP forwarding is
enabled. From the Gateway, you can ping the upstream router and
known sites. But the internal network still has no Internet access. The
Rule Base has not changed. How do you find out if there are any
objects that have been modified, without viewing each object’s
properties?
A.) Select the SmartView Tracker > Audit screen from the console.
Changes to objects and rules are recorded.

30 Check Point Security Administration NGX III

SIC and ICA Issues Chapter 1: General Troubleshooting

SIC and ICA Issues

Secure Internal Communications (SIC) is a Certificate-based channel
between SmartCenter Servers, Security Gateways, Check Point QoS, and
OPSEC application servers. SIC is based on Secure Sockets Layer (SSL),
with digital Certificates. When a SmartCenter Server is installed, a
Certificate Authority (CA) is created by default. As a CA, the
SmartCenter Server is the Internal Certificate Authority (ICA) to all
components it manages. The ICA issues Certificates for all components
that need to communicate with one-another. For example, a Gateway
needs a Certificate from a SmartCenter Server before a Security Policy
can be downloaded, or before a license can be attached using
SmartUpdate. Whenever any two entities (SmartCenter Server, Security
Gateway, OPSEC, or Check Point QoS) need to communicate, the file
sic_policy.conf is referenced.

SIC Port Use

Communication takes place over SIC, which uses the following ports:
Port 18209 is used for communication between NGX Gateways and
ICAs (status, issue, or revoke).
Port 18210 pulls Certificates from an ICA.
Port 18211 is used by the CPD daemon on an NGX Gateway to
receive Certificates.

SIC is completely NAT-tolerant, as the protocol is based on Certificates

and SIC names, not IP addresses. A NAT device between a SmartCenter
Server and Security Gateway does not have any effect on the ability of a
Check Point-enabled entity to communicate using SIC.

Check Point Security Administration NGX III 31

Chapter 1: General Troubleshooting Root Causes

Root Causes
As a baseline for troubleshooting SIC and ICA related issues, test the
following:
Connectivity: Is any traffic (not just SIC) able to reach the Gateway?
Are the necessary ports open and/or available?
Domain name and IP resolution: Verify the entries in the host file are
accurate on the Security Gateway and SmartCenter Server.
Time: If the SmartCenter Server and the Security Gateway are located
in different time zones, verify that a date/time discrepancy is not
causing the conflict.
Certificate Revocation List (CRL): Verify that the SIC Certificate is
not in the CRL, or that the CRL is still reachable for current
Certificates.

32 Check Point Security Administration NGX III

Verifying the Certificate Chapter 1: General Troubleshooting

Verifying the Certificate

View the existing Certificate assigned to the object to verify that
Certificate information is correct for the object. View the certificate in
SmartDashboard by selecting the VPN > Certificates List property of
the specific Check Point Gateway. Select the Certificate to examine, and
click the View button. The Certificate View screen displays:

Figure 1-1: Certificate View of fwoslo’s ICA Certificate

Check Point also includes the ICA Management Tool in VPN-1 NGX,
which can be configured on a SmartCenter Server and used
independently of SmartDashboard to view and manage Certificates:

Check Point Security Administration NGX III 33

Chapter 1: General Troubleshooting Verifying the Certificate

Figure 1-2: ICA Management Tool

Refer to the SmartCenter user guide and sk30501 “Setting up the ICA
Management Tool” at https://supportcenter.checkpoint.com/
supportcenter/index.jsp, for configuration information.

34 Check Point Security Administration NGX III

Maintaining SIC Chapter 1: General Troubleshooting

Verifying Available CPD ports

To determine whether SIC is listening to the cpd ports, use the following
commands:
Windows — netstat -na | find “18211”
UNIX — netstat -na | grep 18211

On SecurePlatform, run this command from the Expert Mode prompt.

Maintaining SIC
The following are recommended best practices to set up and maintain
SIC.
Using Correct FQDN to Initialize ICA
If the FQDN for the SmartCenter Server is not correct, the ICA cannot
initialize successfully. Make sure the FQDN has the correct hostname
and domain name. Make sure the SmartCenter Server’s hostname is
entered correctly in the hosts file.
Avoiding Renaming Gateway Object
The Certificate issued by the ICA (SmartCenter Server) is for a specific
hostname. Once the hostname has changed, the Certificate is no longer
valid. Plan carefully in terms of the naming conventions for all of your
Gateways, including the ICA itself, before you start installing and
configuring. If you must rename the Security Gateway after SIC is
established, follow the steps below to re-establish SIC to the
SmartCenter Server:

Check Point Security Administration NGX III 35

Chapter 1: General Troubleshooting Maintaining SIC

On the relevant Security Gateway:

1. Rename the hostname according to different OS requirements.
2. Reboot the machine, if necessary.
3. Use the cpconfig tool to reinitialize SIC for the newly created
Gateway.
4. Enter a new one-time password.

On the SmartCenter Server, make sure its hosts file has the new
hostname and correct IP address for the relevant Gateway.

From SmartDashboard:
1. Edit the Gateway object.
2. Click Communication > Reset.
3. Rename the Gateway object.
4. Click Communication > Initialize and enter the new Activiation
Key.
5. Click Initialize.

Checking Routing and CPD Connections

Sometimes when testing SIC status on a Gateway object, you might
receive the error “failed to connect to module”. Before reinitializing SIC,
check the following:
1. Make sure routing is present between the SmartCenter Server and IP
address that resolves to the object name shown on the General
Properties screen. Run fw unloadlocal on the Security Gateway if
necessary to test network connectivity.

36 Check Point Security Administration NGX III

Maintaining SIC Chapter 1: General Troubleshooting

2. Make sure cpd-related connections are not blocked by any

intermediate devices from the Gateway and SmartCenter Server, or
vice versa.

If both conditions are met, try to reinitiate SIC with the following steps:
1. On the Security Gateway, use cpconfig to initialize SIC, by typing a
new one-time password.
2. In SmartDashboard and the Communications screen of the Gateway
object, reset SIC.
3. Initialize SIC by typing the same one-time password as used for the
Gateway.
4. To verify SIC click the Test SIC Status button.

Synchronizing clocks
For SIC to initialize successfully, the clocks on the SmartCenter Server
and respective Gateway must be set accurately and synchronized
properly. Verify correct date and time on the operating systems. If the
SmartCenter Server and remote Gateway reside in two different time
zones, the remote Gateway may need to wait for the Certificate to
become valid.
Q.) Your SmartCenter Server is behind your organization’s perimeter
Gateway, with Static NAT configured on the perimeter Gateway. You
have a new NGX Gateway in another city, and you must set up SIC.
When you try to initialize SIC, you receive the error “initialized but not
trusted”. What are reasonable steps to troubleshoot this error?
A.) Check the hosts file on the remote Gateway, and make sure the
SmartCenter’s hostname resolves to its public IP address. Check if there is
any rule in the Policy blocking traffic between the SmartCenter Server and
remote Gateway.

Check Point Security Administration NGX III 37

Chapter 1: General Troubleshooting Resetting SIC

Resetting SIC
The term “resetting SIC” is often used interchangeably for two different
actions. Each has a different level of severity associated with it,
depending on the context.

When working with a Security Gateway, performing a SIC reset refers

to forcing the ICA on SmartCenter Server to update the CRL, so the
specific Gateway’s Certificate has been revoked. The Administrator
then creates a new updated Certificate. When working with a
SmartCenter Server, resetting SIC is referring to initiating the
command fwm sic_reset to revoke all Certificates, and destroying
the existing copy of the ICA.

Resetting SIC is not recommended as a first troubleshooting step to fix a

SIC problem. SIC resetting should be performed as a last resort, and
should be scheduled after business hours.
Before Resetting SIC
Before you reset SIC on a Gateway, make sure you have tested
connectivity, including routes, the Rule Base, etc. To reinitiate SIC, it
may be necessary to unload the Policy on the Gateway by running fw
unloadlocal. The whole network, including the Gateway, is vulnerable
when a Policy is removed. If SIC cannot be established successfully after
you have unloaded the Policy, the next step is to run cpd debug. To
restore the Policy to the Gateway, restart Check Point services by
running cpstop and cpstart. The Gateway will load the previous Policy
from its database, but there will be no logging from the Gateway to the
SmartCenter Server when SIC is broken.
If you have tested connectivity and the Rule Base, and have decided that
resetting SIC is a must, follow these steps carefully:

38 Check Point Security Administration NGX III

Using fwm sic_reset Chapter 1: General Troubleshooting

From the Security Gateway running on Windows:

1. Using cpconfig, select Reset on the SIC tab. Enter the one-time
password twice.
2. Click OK to exit the cpconfig.
From the Gateway on UNIX:
1. Run cpconfig, and select Secure Internal Communication.
2. Enter y to the question “would you like to reinitialize the
communication”.
3. Enter the one-time password twice.
4. Exit cpconfig.

From SmartDashboard:
1. Edit the Security Gateway object, click the Communication button,
and click Reset in the Communication screen. This revokes the
Gateway’s Certificate, and changes SIC status to “Not initialized.”
2. Enter the one-time password twice.
3. Click Initialize. If the connectivity is good and no Policy is blocking
the connectivity, SIC status should read “SIC established” in several
seconds.
4. Install the Policy on the Gateway.

Using fwm sic_reset

Resetting SIC on the ICA (SmartCenter Server) can have serious
implications for Policy installation, logging, and other important daily
functions, such as VPN. Therefore, Check Point does not recommend
resetting SIC on an ICA in most situations, especially in an enterprise
environment where multiple remote Gateways are communicating
through a VPN, using Certificates issued by the ICA. When you reset

Check Point Security Administration NGX III 39

Chapter 1: General Troubleshooting Using fwm sic_reset

SIC on an ICA, VPN tunnels will be interrupted, because all IKE

Certificates are to be destroyed before the ICA can be reset. After the
ICA SIC is reset, you must reset SIC on all managed Gateways.
In some unusual situations, using the fwm sic_reset command is
necessary, for example, when the SmartCenter Server’s hostname is
changed.

Changing the IP address on a SmartCenter Server does not require a

fwm sic_reset.

40 Check Point Security Administration NGX III

Network Address Translation Chapter 1: General Troubleshooting

Network Address Translation

Network Address Translation (NAT) can be used to translate either
source or destination IP address in a connection. When translating the
IP of the machine initiating the connection (typically the “client” of the
connection) this is referred to as Source NAT. When translating the IP
address of the machine receiving the connection this is referred to as
Destination NAT.
VPN-1 supports two types of NAT where the source and/or the
destination are translated:
Hide NAT - Hide NAT is many to one translation, where a single
public address represents multiple computers on the internal
network. This enhances security because connections can only be
initiated from the protected side of the Security Gateway. This type of
NAT is also referred to as dynamic NAT. This is an example of
Source NAT.
Static NAT - Static NAT is a one to one relationship, where each
host is translated to a different public address. This allows
connections to be initiated internally and externally. An example
would be a mailserver that needs to allow connections initiated
externally. When initiating the connection from an external client, the
destination is translated.
NAT can be configured on Check Point hosts, nodes, networks, address
ranges and dynamic objects. NAT can be configured automatically or by
creating manual NAT rules. Manual NAT rules offer flexibility because
it can allow the translation of both the source and destination of the
packet and allow the translation of services.

Hide NAT
In Hide NAT, the source is translated, the source port is modified and
translation occurs server side. As shown in the illustration below, see the
source of 10.1.1.101 going to destination of 192.9.100.10:

Check Point Security Administration NGX III 41

Chapter 1: General Troubleshooting Hide NAT

1. The source 10.1.1.101 initiates a session to 192.9.100.10 with a source

port of of 1305.
2. As the packet hits the interal interface on inspection point i, the
packet is processed by the firewall kernel and forwarded to I where it
is then routed to the external interface.
3. On the inspection point o, it is processed by the NAT rulebase. The
Security Gateway modifies the source port to 12531 and adds the
port information to the state table. The packet translates on O with
the Security Gateway’s external interface of 172.21.101.1.

Figure 1-3: Hide NAT

4. The server replies to 172.21.101.1 and the Firewall maps the source
port from the state table to the original IP and translates back to the
original IP of 10.1.1.101 and the original source port of 1305.

42 Check Point Security Administration NGX III

Static NAT Chapter 1: General Troubleshooting

Static NAT
Static NAT is assigned to a server that needs to be accessed directly
from outside the Security Gateway, so the packet is typically initiated
from a host outside the firewall. When the client initiates traffic to the
static NAT address, the destination of the packet is translated.
Before VPN-1 NGX, all destination NAT occurred at the “server side”
of the kernel, on the outbound side of the kernel closest to the server.
When NAT occurs in this configuration, a host route is required on the
Security Gateway to route to the destination server. As of VPN-1 NGX,
the default method for Destination NAT is “client side”, where NAT
occurs on the inbound interface closest to the client. Assume the client
is outside the Gateway, and the server is inside the Gateway with
automatic Static NAT configured. When the client starts a connection to
access the server’s NAT IP address, the following happens to the
original packet in a client-side NAT:

Figure 1-4: Static NAT

Check Point Security Administration NGX III 43

Chapter 1: General Troubleshooting Static NAT

Original Packet
1. The packet from outside the Gateway arrives at the inbound interface
(pre-in or i) destined for the webserver, and passes Security Policy
and NAT rules.
2. If accepted, the packet information is added to the connections table
and the destination is translated on the post-in side of the interface
(I) before it is routed.
3. The packet arrives at the TCP/IP stack of the NGX Gateway, and is
routed to the outbound interface (o).

The packet is translated, so it is routed correctly without any need to

add a static route to the Gateway.

4. The packet is then forwarded through the kernel (O) and routed to
the webserver.
Reply Packet
1. The webserver replies and hits the inbound interface (pre-in or i) of
the Gateway.
2. The packet is passed by the Policy, since it is found in the
connections table and arrives at the pre-out (I) side of the kernel.
3. The packet arrives at the TCP/IP stack of the Gateway, and is routed
to the outbound interface (post-in or o).
4. The packet goes through the outbound interface and is translated to
the static NAT IP address as it leaves the security Gateway (O). The
source port does not change.

44 Check Point Security Administration NGX III

Debugging NAT Chapter 1: General Troubleshooting

Debugging NAT
In this section we will discuss several useful tools to debugging NAT:
SmartView Tracker
fw monitor
Kernel Debugging

SmartView Tracker
After confirming the configuration of the NAT object and rules in
SmartDashboard, open SmartView Tracker to view the traffic leaving
the Security Gateway. Go to View > Query Tree and choose xlate src
and xlate dst. This will show source and destination NAT for packets
running in and out of the Security Gateway.
For example, a host on the inside network is being hide translated
behind the Security Gateway. The src field should show the physical IP
address of the client. The xlate src column should show the translated
address.

Figure 1-5: Showing NAT in SmartView Tracker

Check Point Security Administration NGX III 45

Chapter 1: General Troubleshooting Debugging NAT

fw monitor
Another useful troubleshooting tool is running fw monitor on the
Security Gateway to determine if the packet is translating. Take the
example above. In the fw monitor the src packet will hit the inspection
points i, I, o and then O the packet will translate to the external interface
of the firewall. For more information regarding inspection points
through the firewall kernel, see Chapter 5 Protocol Analyzers.
Another example, is a webserver behind the Security Gateway that is
statically translated. In this example, the webserver is translated to a
specific IP address on the same network as the external interface. The
fw monitor capture can show if translation is happening client-side or
server-side.
Kernel Debugging
The primary command for observing the NGX kernel’s actions on a
packet is fw ctl debug. It is also used for configuring debugging on
almost any action that VPN-1 NGX can take on a packet or connection.
The standard format for the command is as follows:
fw ctl debug
Running this command from the CLI produces a list of currently
running modules and debugging flags. When the command is issued
with an argument following it, the default kernel module acted on is the
fw module.
Some of the more commonly used arguments for fw ctl debug include:
-buf Sets the buffer size used by the debug process for this session
+ <flag_name> Sets the debugging to add the listed flag(s) to the currently
flagged and running session
Note: Adding a flag name to the command without the + ,
such as ...
fw ctl debug smtp
... Sets the debugging session to that flag only.

Table 1-6: fw ctl debug Arguments

46 Check Point Security Administration NGX III

Debugging NAT Chapter 1: General Troubleshooting

0 Resets all debugging flag values to default settings

-m Specifies which modules will be flagged in the running ses-
sion
kdebug -f >& Writes the output of the debugging session to the declared
<filename> filename

Table 1-6: fw ctl debug Arguments

The debugging NAT process below is annotated with information about

using fw ctl debug. Run the following from the $FWDIR\bin directory:

Debug Explanation

fw ctl debug 0 Resets debugging flags to default settings

fw ctl debug -buf 2048 Sets the debugging buffer to 2 KB
fw ctl debug xlate xltrc Turns off all currently running flags and only debugs
using these two flags on the fw module
fw ctl kdebug -f >& / Writes the output of this debugging session to the
tmp/kdebug.out declared path and filename.

Table 1-7: fw ctl debug Process

These commands debug the NAT process in the kernel, and produce
output with debug information. To reset debugging flags, run fw ctl
debug 0.

Check Point Security Administration NGX III 47

Chapter 1: General Troubleshooting Debugging NAT

48 Check Point Security Administration NGX III