What is EndPoint Connect

Check Point`s Endpoint Connect software provides a number of client side security based features such as Anti-virus/Anti-spyware. Firewall/Email Protection, Program Control and Remote Access VPN. This document will only details and discuss the Remote Access VPN section of the Endpoint Connect Software. Note : This document will refer to the Endpoint Connect Remote Access VPN as just Endpoint Connect.

Endpoint Connect is built into the software for mangers and gateways running R70 and above. For R65 gateways that require Endpoint Connect a few additional configuration steps are required which are included within this document.

Please note : This testing and documentation is based on the Endpoint Connect R73 Client.

Advantages

• Lightweight Client if you are using a single site or single entry point setup.
• Can be installed onto Windows 7 64-bit.

Disadvantages

• An additional SNX (SSL Network Extender License) is required due to that in which it authenticates across HTTPS (vistor mode)
• Link Selection is disabled (this is due to sites being defined via a single IP address).
• MEP configurations can only be achieved by using Geo-Cluster DNS name resolution.

Installation on an R65 Gateway

Upgrading a R65 Gateway to R65 Endpoint Connect:

1. Ensure that you are running HFA40 or higher.
2. Ensure that you are managing the gateway with R70 or higher.

You will now be able to configure the required Endpoint Connect settings via the Smart Dashboard.

Configuration

To enable Endpoint Connect configure/enable the following settings :

Under the Check Point Gateway Object

1. Enable VPN

2. Create a VPN domain

3. Enable NAT-T

4. Enable Visitor Mode :

5. Enable Office mode

6. Enable SSL Network Extender

7. Endpoint connect doesn`t support DES. If this is set please re-configure.

Additional Settings

Further settings can be set within the Global Properties:

Troubleshooting

Issue : Authenticating failed: GEN_application_error(0)

You may receive this error when trying to login.

This is down to your client being unable to authenticate with the VPN gateway using HTTPS. This can be caused by the following:

            1.      Port 443/tcp on the firewall is assigned to a web management GUI (WEBUI/Voyuger) instead of VPND.
            2.      Port 443/tcp is not listening due to no SNX (SSL Network Extender) License being present.

Issue : Failed to download topology

Endpoint Connect fails to connect to NGX R65 Security Gateways that are managed by an R70 Security Management server with error: "failed to download topology".

To resolve this run through the following steps :
          1.      On the R70 Security Management server, edit the file:

1./opt/CPNGXCMP-R70/lib/vpn_table.def

         2.      Scroll down to the section that starts with:

1./* Slim Client gateway tables */

         3.      Add the entry for the ccc_sessions table below it:

1.ccc_sessions            = dynamic expires 900 keep sync kbuf 1;

         4.      After adding this entry to the vpn_table.def file, open SmartDashboard and re-install policy to the NGX R65 Security Gateway(s).

How to troubleshoot SSHd problems

1. Is sshd wrapped with tcp-wrappers? Assuming the sshd daemon is invoked from inetd, your /etc/hosts.allow should list acceptable addresses from which connections are allowed.

2. Is sshd running on the standard port 22 or another? If running on a non-standard
port, make sure that your ssh client is specifying the target port.

3. Which sshd version is running? There are many problems with sshd2 used in
conjunction with tcp-wrappers. sshd1 runs with fewer difficulties wrapped. Also, the
ssh1 client has difficulty connecting to a sshd2 server.

4. Make sure that your /etc/services reflects the ssh service on the designated
port! /etc/services and tcp-wrappers work together when invoking the sshd daemon.

Example: sshd1 running on port 700 should have an entry in /etc/services as such:

ssh1        700/tcp    #ssh1
ssh1        700/udp

While in inetd.conf, the invoking line should read:

ssh1    stream  tcp     nowait  root    /usr/sbin/tcpd /usr/local/sbin/sshd1 -i -p 700

Does Webtrends use ELA

Webtrends uses LEA (Log Export API), not ELA.  LEA is the opposite of ELA; it allows FW-1 to send events to a 3rd party reporting application. Although it is possible to use Webtrends with manually exported log files, I believe they recommend using LEA as the preferred interface between the two.

Per Check Point: "WebTrends Firewall Suite integrates with the Log Export API (LEA) of the OPSEC architecture in VPN-1/FireWall-1. When LEA is used, a secure connection is set up between WebTrends Firewall Suite and VPN-1/FireWall-1. This connection provides the mechanism that safely and securely transfers data between the firewall and the analysis engine. By encrypting data at the firewall, LEA ensures that firewall logs are not tampered with during transport. The LEA connection also facilitates the creation of real-time reports without the need to export complete log files at every update interval, saving time and bandwidth resources."

How do I Rotate the Audit Logs in FireWall-1 NG

The VPN-1/FireWall-1 NG audit log type files are:

        

           xx.adtlog - stores the audit log records.

           xx.adtlogptr - provides pointers to the beginning of each log records.

           xx.adtloginitial_ptr - provides pointers to the beginning of each log chain (logs that shared the same  

           connection ID - LUUID). 

           xx.adtlogaccount_ptr - provides pointers to the beginning of each accounting record.

 

To purge/delete the current audit log files without saving it to a backup file, run:

# fw logswitch -audit ""

To logswitch and save the logs to a file, run:

# fw logswitch -audit

Example :

 

# fw logswitch -audit
 Trying to switch audit logfile to 2002-06-07_150016.adtlog
 Log File was switched to : 2002-06-07_150016.adtlog

Secure Client through a FireWall-1 Firewall

I have an internal local user who is connected to our local network, and he is interesed in using securemote to connect to one of our customers who provide him the necessary information to get into their site. Both our site and the customer site use FireWall-1. The user is able to ping and see the customer's hosts but some of the packet will not go through our firewall.
If the same user uses the modem or dialup from the ISP internet connection he is able to do everything he needs to with securemote, but we are interested in providing connectivity within internal lan to remote customer site.


If your firewall is not performing any address translation on the securemote client, then it will work with the information provided below. If your firewall is doing address translation for the securemote client (because the client has a non-routable or illegal IP address), then read the following FAQ to determine if such a configuration will be possible: Secure Client and NAT
Assuming you are not doing address translation or can workaround it, part of what needs to be done will depend on whether or not the remote FireWall-1 is configured to use encapsulation for securemote connections or not.
General Configuration
In all cases, you will need to permit the following traffic through your local firewall (note only use IKE for FireWall-1 4.0 and above when IKE is used for securemote, in 4.0 the service is named ISAKMP):

Source                   Destination              Service                    Action
                                                  FW1
securemote-Client        Remote-Mgmt-Server       FW1_topo                   Accept
                                                  FW1_pslogon

securemote-Client        Remote-FireWall          RDP                        Accept
                                                  IKE

Remote Site Uses fwz Encapsulation
If the remote site is using encapsulation for securemote clients, the following additional rule needs to be added:

Source                   Destination               Service             Action
securemote-Client        Remote-FireWall           FW1_Encapsulation   Accept
Remote-FireWall          securemote-Client

FW1_Encapsulation is pre-defined on most current FireWall-1 boxes. If it is not pre-defined on yours, then create it as service of type Other with \"ip_p=94\" in the Match field.
Remote Site Uses IKE
If the remote site is using IKE for securemote clients, the following additional rule needs to be added:

Source                   Destination              Service             Action
securemote-Client        Remote-FireWall          ESP                 Accept
Remote-FireWall          securemote-Client

ESP is pre-defined on most current FireWall-1 boxes. If it is not pre-defined on yours, then create it as service of type Other with \"ip_p=50\" in the Match field.
Remote Site Uses UDP Encapsulation
If the remote site is using UDP Encapsulation on their clients, the following additional rule needs to be added:

Source                   Destination              Service                  Action
securemote-Client        Remote-FireWall          VPN1_IPSEC_encapsulation Accept
Remote-FireWall          securemote-Client

VPN1_IPSEC_encapsulation is pre-defined on FireWall-1 4.1 SP3 and above. If it is not pre-defined on yours, then create it as service of type UDP, port 2746.
Remote Site uses fwz without Encapsulation
If the remote site does not use encapsulation, then you will need to permit the necessary traffic to and from the remote site by your local firewall's rulebase. You need to make sure that none of the traffic is processed through the security servers or an intermediary proxy or you might get unreliable or unpredictable results. The following rule near the top of your rulebase should suffice:

Source                   Destination               Service             Action
securemote-Client        Remote-Servers            Any                 Accept

The \"any\" above can be replaced with the specific services the securemote client needs to use.
Remote Site uses NG, Policy Server, and Office Mode
If you are using Office Mode on FireWall-1 NG and/or using the Policy Server for NG, you will need the following rules:

Source                   Destination              Service                  Action
securemote-Client        Remote-FireWall          FW1_pslogon_NG           Accept
                                                  IKE
                                                  VPN1_UDP_Encapsulation
                                                  Tunnel-Test

FW1_pslogon_NG is TCP port 18231. Tunnel-Test is UDP Port 18234.

SecureRemote from behind a NAT device

How to encrypt data between an SR Client behind a NAT device and the LAN behind FW-1,

You have to distinguish 2 situations

1) Static NAT, Pool NAT, 1 user behind a Hide NAT

2) Hide NAT with multiple users

In the following configuration you solve it for situation 1) :

SR Client ------ NAT device (FW or other) ----- Internet ------ FW-1--- LAN

For this configuration you need VPN-1 version 4.1.

It it supported with FW-1 4.0 (and SR versions above SR4003) by making the following modifications

Stop FireWall-1 with the command

fwstop

Edit the $FWDIR/conf/objects.C file and add (or modify) the following lines which are under the property

set props : :userc_NAT (true) for FWZ,

and :userc_IKE_NAT (true) for ISAKMP (IKE).

Restart FireWall-1 with the command fwstart Install the policy.

Confirm that these changes appear both in $FWDIR/conf/objects.C and in $FWDIR/database/objects.C For Static NAT and Pool NAT, this configuration works fine with the FWZ and IKE encryption schemes.

This works with Static NAT and Pool NAT fine. For Dynamic NAT, it will only work if there is a single SR client behind each hiding IP address.

2) If you are subject to address translation, it is highly recommended to use IKE instead of FWZ. Both encapsulated and unencapsulated FWZ are known not to work with HIDE NAT at all. Static NAT (1-to-1 address mapping) should work with FWZ in either mode provided you allow IP Protocol 94, UDP Port 259, and other services if you use FWZ in unencapsulated mode. However, most NAT gateways will reject unencapsulated FWZ packets because the checksums are changed to support the FWZ encryption scheme.

If you are subject to any form of NAT, IKE is your best bet. However, most NAT gateways can not be configured to perform HIDE NAT on generic IP Datagrams. Provided you can forward UDP Port 500 packets and IP Protocol 50 (IPSEC) packets with your NAT gateway, you can use IKE with NAT.

Secure Client 4.1 SP2 and later when used with FireWall-1 4.1 SP2 and later support a 'UDP Encapsulation Mode' for IKE. Instead of using IP Protocol 50, UDP port 2746 is used. Most NAT gateways can perform address translation on UDP packets and it is designed to work with HIDE NAT, meaning multiple users can make use of SecuRemote behind a HIDE NAT gateway. Provided your clients are able to use TCP port 264 to fetch the topology, UDP port 500 to perform an IKE key exchange, and UDP port 2746, this should work.

You will need to modify objects.C on the management console to permit FireWall-1 to accept connections from NATted SecuRemote users. Edit $FWDIR/conf/objects.C. After the props: line, add:

:userc_NAT (true)
:userc_IKE_NAT (true)

To configure the UDP Encapsulation Mode for FireWall-1 4.1 SP2, create a service called VPN1_IPSEC_encapsulation if it does not already exists. Create it with port UDP 2746. Then add the following section to the section with your gateway object to objects.C:

:isakmp.udpencapsulation (
:resource (
:type (refobj)
:refname
("#_VPN1_IPSEC_encapsulation")
)
:active (true)
)

You have to add this in between the properties defined for your firewall object. Search the Objects.C file for the name of the firewall object ( through which you would like to the UDP encapsulation enabled ) and add these lines in between the various features configured for your firewall object.

Re-install the policy.

Note that in the default configuration, FireWall-1 will determine whether or not to use this mode based on the source port of the incoming UDP 500 packet. If it comes from source port 500, it will not use the UDP encapsulation mode. If it comes from a different source port, UDP encapsulation mode will be used. More details and instructions for disabling or forcing this mode can be found in the Secure Client 4.1 SP2 Release Notes.

Description of UDP Encapsulation. Seeing UDP encapsulation is a new feature and I was concerned about it affecting the users with older securemote software, here is a quick and dirty explanation of UDP Encapsulation. 

1. SR sends IKE packet to VPN-1, one of the IKE proposals it sends to the gateway is to use UDP encapsulation. Note, only SP2 clients can send this UDP encap proposal, SP1 or earlier clients, cannot. 

2. If IKE negotiation (port UDP-500/500) packet's SRC PORT has NOT been translated, then no UDP encapsulation, it just operates like normal SR IKE session (thus SP2 and SP1 and earlier SR's can run side by side against a single gateway): a standard proposal is selected and a VPN tunnel is established. 

3. If IKE SRC PORT != 500, then the gateway assumes that a NAT HIDE device is between the gateway and SR. Then, and only then, does it accept the UDP encapsulation proposal. This selection is communicated to the client. 

4. The client takes note of the selected IKE Proposal (encap or a "normal" one) and if encap, wraps the IPSEC traffic in a UDP packets. It is actually quite an elegant solution, as it is end user transparent and encapsulation (i.e., the extra overhead) is only used when needed... when the SR client is behind such a NAT device. When the SR client is moved to another non-NATed network, no encap takes place.
 

What do IP Pool features do, in 4.1. This has something to do with NATof inbound traffic, but why one would want to NAT inbound traffic.

The main reason for this new feature is to properly handle internal network routing, when a company's internal network is connected to the Internet in multiple places. 
Prior to version 4.1, if a SecuRemote VPN was established through one of the company's firewalls, the Internet routable source IP address would have to be passed into the internal network.  This works fine, so long as the path back out to the Internet goes through the same firewall original packets came in on. 
However, several large companies now have multiple Internet connections, which poses a unique problem.  If you were to route the Internet routable source address through one firewall, and then try to access internal resources in another office that had it's own Internet connection, there is a high probability that return packets would be routed through the second office's Internet connection, and thus break the VPN.  It is for this reason, that Check Point added new functionality to allow you to "hide" incoming VPN traffic.  This way, one can add specific internal routes to get VPN return traffic back to the specific firewall it came from.

How to have SecuRemote Access to an internal DNS for DNS resolution

the internal DNS server’s IP address

 Modify the $FWDIR/conf/dnsinfo.C file on the Management Station to redirect DNS by providing the following information.
        
         the domain for which it resolves names 
         the maximum number of labels to resolve (for example, 3 for xxx.hello.com). Suppose the SecuRemote Client’s domain is .hello.com and it fails to resolve yyy.goodbye.com. By default, Windows will then try to resolve yyy.goodbye.com.hello.com, and you will probably not want this query to be encrypted.  
         the network addresses for which it resolves (for reverse DNS)

In $FWDIR/conf/dnsinfo.C, 
set :encrypt_dns (true) under :dnsinfo.

Instruct the gateway to encrypt DNS by changing the definition of
USERC_DECRYPT_SRC in crypt.def.

Reinstall the Security Policy on the gateway so that these changes take effect.

On the SecuRemote Client, 
set :dns_encrypt (true) 
under :options in database\userc.C.
Note – :dns_encrypt (true) is the default in VPN-1/FireWall-1 Version 4.1 and higher.

What is SecureClient

It is SecuRemote configured with the Desktop Security feature.
SecureClient == SecuRemote EXCEPT that SecureClient has the capability to function as a "mini-firewall" to prevent hijacking of SecuRemote sessions (this is the "Enable desktop security support" option you see during install
of SecuRemote 41xx - that's the ONLY difference from an install perspective). To use it without the "mini-firewall" functionality, it is free. To use the SecureClient functionality, however, you must purchase licenses for it, which you would install on the management station. You will also need a policy  server function. This also requires FW1 v4.1/2000. Version 4.0 does not offer SecureClient functionality.

How does SecuRemote work

     IKE: Allows for DES or 3DES to be used to encrypt the packets. Packets are encapsulated in IP Protocol 50 (i.e. IPSEC) or UDP port 2746, depending on whether or not UDP Encapsulation is used.  

    fwz without encapsulation (available in NG FP1 and before): Uses fwz1 or DES to encrypt the packets. Only the data portion of the packet is encrypted. The IP headers are left alone.

    fwz with encapsulation (available in NG FP1 and before): Same as above, except packets are encapsulated in IP Protocol 94 packets.

   

    Visitor Mode (NG AI and above): Tunnels using a standard HTTPS stream. By default, runs over port 443, but can use any port.

When using Transparent Mode in NG, or using 4.1 and earlier, the securemote client will, as it deems necessary, establish an encrypted session with the firewall. Before it can do this, the securemote client needs to know what hosts it can talk to encrypted and what the encryption keys are. This is accomplished by fetching the site from the remote server. This happens on TCP port 264 to the firewall module. securemote 4.0 used TCP port 256 to the management station.

In NG when using Connect Mode, the connection to the encryption domain is controlled by the end user. The connection dialog looks very similar to a dial-up networking. The user can select the site he wishes to connect to, change options, and then connect. Optionally, the start of the VPN connection can be tied into the domain logon in Windows 2000/XP.

Once securemote determines that it needs to encrypt traffic to the firewall, authentication is performed. Authentication can be a simple password, SKey, SecurID, or a certificate, but all data between the firewall and the client is encrypted so the password (even if it is a simple password) is not divulged in the clear. This happens between the firewall and the client on UDP port 259 (source port and destination port) if fwz is used or on UDP port 500 if IKE is used.

What model of DSL routers works best with SecuRemote/SecureClient

Here is the result of different tests performed with DSL routers and SecuRemote.

Checkpoint Safe@Home (s-box) works fine

Linksys They are working with SecuRemote. The only issue with Linksys is that they only support a single IPSEC connection from behind the router. I had a Linksys BEFSR41 router and have multiple computers at home, and for the longest time, was wondering why I was having connection/stability problems. I then found out from Linksys' web site that there routers only support a single IPSEC connection.

SMC routers, as we have not had a single problem with them.

NetGear products work fine

3Com officeconnect DSL gateway works fine

Netopia 3351 works fine

Cisco 678 works fine

D-Link 614+ could not work but 714 worked out of the box.

W-Linx 401,  is working perfectly.


Is it possible to use an answer file for SecureClient installation

Is possible to use an answer file with a SecuRemote installation (Build 4200) to be specific? This allows the ability to blindly answer the questions during the install, without the end user having to do anything.

This is possible. In NG FP2/3 checkpoint also ships a tool for modifying these settings. Use the "Secure Client Packaging tool" that is available from the checkpoint site.

You have to install the packaging tool on a machine that has SecuRemote/SecureClient installed and configured. Then run through the options and when it gets to the part where it asks for the Client installed files point it to the directory where it is installed on the current machine (c:\Program Files\Checkpoint\SecuRemote or something close to that) Then generate your package. Now install it on a TEST machine everything should be there.

 

NG SecuRemote license

The securemote license is separate from other firewall licenses, so if you have a license installed on your management server that contains a string

like (Assuming NG) "CPVP-VSR-XX-NG", you are licensed for securemote. If you don't have a license with this product code in it attached to your

management server, then you aren't licensed. The license is free (as in beer), contact your Checkpoint supplier to obtain one.

How to change the log directory

To direct Log File to directory different then the standard $FWDIR/log. On UNIX system this can be achieved by adding

setenv FWLOGDIR

to the fwstart scripts before running the fwd and them fwm.

To do this in NT, you must upgrade your software to 3.0b, and then use the Registry Editor to add to the key

HKEY_LOCAL_MACHINE\SOFTWARE\CheckPoint\FW1

the value FWLOGDIR with the desired path of the directory (which must exists).

Authentication in more than one NT domain

What ports are used for a trust relationship

PORT 135 TCP or UDP RPC services
PORT 137 UDP Netbios name service
PORT 138 UDP Netbios datagram
PORT 139 TCP Netbios session
All port above 1024 for RPC communication

How to remove old licenses

Use fw printlic to view the current license situation, and then re-enter your current license string (eval or permanent key) with a -o option. This will overwrite all existing licenses.
fw putlic -o ...

message "to many hosts", what shall we do to unlock the situation

To remove firewall license limitation use the procedure:

fw lichosts
rm $FWDIR/database/fwd.hosts
rm $FWDIR/database/fwd.h
fwstop
fwstart

 

licenses for SecuRemote with NG AI

Chkpnt NG with AI supports 2 licensing schemes - local and central. If you have multiple Enf modules(EM) and a single SmartCenter server(SCS) to manage all of them - go for central licensing. Central licensing is useful in such cases because even if the EM IP address changes you dont need to regenerate ur license, the only time you need to regenerate your license would be in case if you change the SCS IP(which is rarely the case). Go for Local licensing when you have the SCS and EM on the same machine - standalone configuration. In this case, if you change the IP of your EM, you need to regenerate ur License. Tedious ha ?
SCS always requires a LOCAL license in any case.
This may come as a BOOMER to you - if you have already procured the product with local licensing - and already generated it from usercentre.checkpoint.com - nothing can be done about it now.
If you have not yet purchased the product 
- I would suggest you go for centrallicensing as its better in your case.

What are the meanings of the different files to backup

Of largest significance are your policy file, .W, and objects.C -- from these two you can regenerate the rulebases.fws file
(./fw m -g *.W). 

The cp.license file may be useful, but if you know your certificate key, you can request a copy of it from the checkpoint license site. 

The fwauth.NDB (mgmt. module only) file keeps information about your users & user-groups, so unless you're not doing any authentication or
securemote (minus LDAP stored users..), you'll want to grab this file too. 

The fwauth.keys file contains all the putkeys you've set -- backing this up probably isn't necessary since you'll have to redo the putkeys
anyways.  This may not be existant if in single gateway mode with no opsec add-ons tied into it.

The fwmusers (mgmt. station only) file contains all the usernames and passwords (including permissions), for GUI-Client access.

The gui-clients (mgmt. station only) file tells which remote systems are allowed to log into the management station via the GUI and manage it.

The masters file (fw module only) just has the address of the management server in it. 

The product.conf file tells which options you have purchased, want turned on, and such.. restoring it will save some reconfiguring.

The seed file will allow you to utilize the parts that are stored encrypted -- user passwords and such.  Without it, expect to change a
lot of passwords.

The sync.conf (fw modules only) file is used when doing high-availability state-synchronization.

The serverkeys file (or serverkeys.* on unix) are hashes of the putkeys (fwauth.keys file). 

FW-1 and Y2000

After we has tested Firewall-1, we found that Firewall-I was
miscosistent in creating log file.Before Year 2000, Firewall-1 creates the log file in such manner :

xxxMMDDYY.log

where xxx is the time the log file created
MM is the month the log file created
DD is the date the log file created
YY is the year the log file created (1999 will be 99)

Example :
the log file created on Sep 8, 1999 will has the name xxx090899.log
the log file created on Dec 31, 1999 will has the name xxx123199.log

After Year 2000, Firewall-1 creates the log file in such manner :

xxxMMDDYYY.log

where xxx is the time the log file created
MM is the month the log file created
DD is the date the log file created
YYY is the year the log file created (2000 will be 100,
2001 will be 101)

Example :
the log file created on Jan 1, 2000 will has the name xxx0101100.log
the log file created on Feb 28, 2000 will has the name xxx0228100.log

The "100" represents the number of years since 1900. A number of
applications work this way.

NAT how does it work

Yet another attempt to explain NAT, since every time I do it I'm unsatisfied
with the clarity of the result. This time it follows the progress of a TCP
SYN packet from an external client to an NAT'd server and the server's
SYN+ACK response.

SCENARIO

The simplest of set-ups - an ISP router, FW-1 and a single internal host
with an RFC1918 address. All boxes are assumed to have just been booted,
i.e. routing entries present but ARP tables empty. Addresses as follows :-

INTERNET
|
ISP Router
a.b.c.1 / 010101010101 (IP/MAC)
|
a.b.c.254 / 020202020202
Firewall-1
192.168.1.1 / 030303030303
|
192.168.1.2 / 040404040404
Internal Host (public address = a.b.c.2)

NARRATIVE

We'll start at the point where the remote client's (x.y.z.8) TCP SYN
datagram has reached the ISP router via its Internet i'face. At this point
the relevant addresses are as follows :-

Src MAC = Some other Internet router's
Dst MAC = MAC address of Internet interface of ISP Router
Src IP = x.y.z.8
Dst IP = a.b.c.2

The router looks in its routing table and sees that the a.b.c.0 subnet is
locally attached, so as far as it's concerned the next hop is the Dst IP
address itself. The router sees that it has no MAC address for a.b.c.2 and
does an ARP broadcast out of its a.b.c.1 interface. There's no real host
with address a.b.c.2 to reply to the ARP but if you've set the Firewall up
properly (published ARP entry in Unix, local.arp file entry in NT) it will
reply giving 020202020202 as the MAC address for the IP address a.b.c.2.

The router is now happy, puts an entry in its ARP table to save having to
ARP again (for a while), changes the Src MAC address of the datagram to that
of its a.b.c.1 interface and the Dst MAC address to that of the Firewall (as
per the new ARP entry), thus :-

Src MAC = 010101010101
Dst MAC = 020202020202
Src IP = x.y.z.8
Dst IP = a.b.c.2

The card driver on the external side of the Firewall passes the datagram to
the firewall module which checks that it has a rule allowing x.y.z.8 to talk
to a.b.c.2. It has, so it sticks an entry in the connection table and passes
the datagram up to the IP level UNCHANGED.

IP looks at it and says 'this is not for me' and looks in its routing table.
Since routing always uses the most specific matching entry (i.e. host first,
subnet second, network third and default last) it finds your manually-added
routing entry saying that the next hop for a.b.c.2 is 192.168.1.2. It
doesn't have a MAC address associated with 192.168.1.2 but knows that it is
on the 192.168.1.0 subnet so does an ARP broadcast out of its 102.168.1.1
interface. The Host replies, the FW's IP stack creates an ARP entry and
changes the MAC addresses of the datagram again as follows :-

Src MAC = 030303030303
Dst MAC = 040404040404
Src IP = x.y.z.8
Dst IP = a.b.c.2 (STILL!)

The IP stack passes the datagram down to the firewall module which notes the
need for address translation, alters the Dst IP address to 192.168.1.2 and
records an entry in the translation table. Now we have :-

Src MAC = 030303030303
Dst MAC = 040404040404
Src IP = x.y.z.8
Dst IP = 192.168.1.2

The firewall module passes the translated datagram to the card driver which
pops it on the 192.168.1.0 network.

The Host's IP stack receives a TCP SYN datagram with its MAC address and IP
address, passes it to the listener which replies with a SYN+ACK datagram
addressed to x.y.z.8. The Hosts's IP stack looks at its routing table, sees
the default routing entry pointing to 192.168.1.1, realises that it doesn't
have an ARP entry for 192.168.1.1, does an ARP request, stores the result
and forwards the datagram as follows :-

Src MAC = 040404040404
Dst MAC = 030303030303
Src IP = 192.168.1.2
Dst IP = x.y.z.8

The card driver on the internal interface of the firewall passes the
datagram to the firewall module which sees the entry in the translation
table and modifies the source address of the datagram to a.b.c.2. The module
then looks in the connection table, sees that this is part of an established
connection and passes it up to the IP stack.

The IP stack says 'this is not for me', looks in its routing table,
eventually matches against the default entry pointing to a.b.c.1, ARPs to
get the MAC address of a.b.c.1, adds an ARP table entry, modifies the MAC
addresses and forwards the datagram as follows :-

Src MAC = 020202020202
Dst MAC = 010101010101
Src IP = a.b.c.2
Dst IP = x.y.z.8

and thereafter normal routing takes care of the datagram.

                                                      CP,FW &FWM

cphaprob stat                                 List cluster status
cphaprob -a if                                 List status of interfaces
cphaprob syncstat                         shows the sync status
cphaprob list                                  Shows a status in list form
cphastart/stop                                Stops clustering on the specfic node
cp_conf sic                                    SIC stuff
cpconfig                                         Config util
cplic print                                        Prints the license
cprestart                                         Restarts all Check Point Services
cpstart                                            Starts all Check Point Services
cpstop                                            Stops all Check Point Services
cpstop -fwflag -proc                      Stops all checkpoint Services but keeps policy active in kernel
cpwd_admin list                            List checkpoint processes
cplic print                                        Print all the licensing information.
cpstat -f all polsrv                          Show VPN Policy Server Stats
cpstat                                             Shows the status of the firewall

  
fw tab -t sam_blocked_ips           Block IPS via SmartTracker
fw tab -t connections -s                 Show connection stats
fw tab -t connections -f                  Show connections with IP instead of HEX
fw tab -t fwx_alloc -f                       Show fwx_alloc with IP instead of HEX
fw tab -t peers_count -s                Shows VPN stats
fw tab -t userc_users -s                Shows VPN stats
fw checklic                                                              Check license details
fw ctl get int [global kernel parameter]                 Shows the current value of a global kernel parameter
fw ctl set int [global kernel parameter]  [value]    Sets the current value of a global keneral parameter. Only 

                                                                                 Temp ; Cleared after reboot.    
fw ctl arp                                                                  Shows arp table
fw ctl install                                                              Install hosts internal interfaces
fw ctl ip_forwarding                                               Control IP forwarding
fw ctl pstat                                                              System Resource stats
fw ctl uninstall                                                         Uninstall hosts internal interfaces
fw exportlog .o                                                       Export current log file to ascii file
fw fetch                                                                   Fetch security policy and install
fw fetch localhost                                                   Installs (on gateway) the last installed policy.
fw hastat                                                                Shows Cluster statistics
fw lichosts                                                              Display protected hosts
fw log -f                                                                  Tail the current log file
fw log -s -e                                                             Retrieve logs between times
fw logswitch                                                           Rotate current log file
fw lslogs                                                                 Display remote machine log-file list
fw monitor                                                              Packet sniffer
fw printlic -p                                                           Print current Firewall modules
fw printlic                                                               Print current license details
fw putkey                                                               Install authenication key onto host
fw stat -l                                                                 Long stat list, shows which policies are installed
fw stat -s                                                               Short stat list, shows which policies are installed
fw unloadlocal                                                      Unload policy
fw ver -k                                                                Returns version, patch info and Kernal info
fwstart                                                                   Starts the firewall
fwstop                                                                   Stop the firewall

   
fwm lock_admin -v                                              View locked admin accounts
fwm dbexport -f user.txt                                       Used to export users , can also use dbimport
fwm_start                                                              starts the management processes
fwm -p                                                                   Print a list of Admin users
fwm -a                                                                   Adds an Admin
fwm -r                                                                    Delete an administrator

Provider 1
mdsenv [cma name]                                           Sets the mds environment
mcd                                                                      Changes your directory to that of the environment.
mds_setup                                                          To setup MDS Servers
mdsconfig                                                           Alternative to cpconfig for MDS servers
mdsstat                                                               To see the processes status
mdsstart_customer [cma name]                      To start cma
mdsstop_customer [cma name]                      To stop cma
cma_migrate                                                     To migrate an Smart center server to CMA
cmamigrate_assist                                           If you dont want to go through the pain of tar/zip/ftp and if                                                                   you wish to enable FTP on Smart center server

                                                            VPN Related Commands
 

vpn tu                                                                               VPN utility, allows you to rekey vpn
vpn ipafile_check ipassignment.conf detail‏                Verifies the ipassignment.conf file
dtps lic                                                                             show desktop policy license status
cpstat -f all polsrv                                                           show status of the dtps
vpn shell /tunnels/delete/IKE/peer/[peer ip]                 delete IKE SA
vpn shell /tunnels/delete/IPsec/peer/[peer ip]             delete Phase 2 SA
vpn shell /show/tunnels/ike/peer/[peer ip]                   show IKE SA
vpn shell /show/tunnels/ipsec/peer/[peer ip]               show Phase 2 SA
vpn shell show interface detailed [VTI name]             show VTI detail

                                                                  Debugging

fw ctl zdebug drop                                  shows dropped packets in realtime / gives reason for drop

                                                                SPLAT Only

router                       Enters router mode for use on Secure Platform Pro for advanced routing options
patch add cd            Allows you to mount an iso and upgrade your checkpoint software (SPLAT Only)
backup                    Allows you to preform a system operating system backup
restore                     Allows you to restore your backup
snapshot                  Performs a system backup which includes all Check Point binaries. Note                                    This issues a  cpstop
VSX
vsx get [vsys name/id]                          get the current context
vsx set [vsys name/id]                          set your context
fw -vs [vsys id] getifs                            show the interfaces for a virtual device
fw vsx stat -l                                           shows a list of the virtual devices and installed policies
fw vsx stat -v                                          shows a list of the virtual devices and installed policies (verbose)
reset_gw                                                resets the gateway, clearing all previous virtual devices and settings.