How to perform a clean installation of firewall-1 on a Nokia Platform

   1) In the Voyager interface, use the Manage Installed Packages to turn off the package, then reboot
    2)In the Voyager interface, on the Manage Installed Packages page, there is a link to a page to delete packages. Follow this link and delete the package
    3)Use a console connection to delete any remaining log files. For example, FireWall-1 maintains its logs in the /var/fw/log directory. Simply issue an
    # rm /var/fw/log/*
    4)command to remove all log files.
    Use the "newpkg" command to reinstall the package.
 

How to switch logs on a Nokia system

Here below is an example of log rotation for IPSO

#!/bin/sh
#
# Set environment variables
sh /var/etc/rcm_profile
#
cd /var/fw/log
#
# Switch CheckPoint log into dated file for saving
# Surpress resolving of IP/names
PERIOD=`date "+%d%m%y"`
$FWDIR/bin/fw logswitch $PERIOD 2> /dev/null
#
# output logfile to comma seperated variable file
$FWDIR/bin/fw logexport -d , -i $PERIOD.log -o yesterday -n 2> /dev/null
#
# search for all dropped packets
ATTACK=$PERIOD.attack
grep "drop" yesterday >> $ATTACK
#
# uuencoded files will be interpreted as an attachment by most mail clients
uuencode $ATTACK $PERIOD.csv > $PERIOD.csv
#
# mail attack to system administrator
mail -s "Fire Log Switch" fwadmin@corp.com < $PERIOD.csv

How to perform a local simulation for a remote module in order to configure it before shipment

Simulation is usefull when you are preparing equipments for remote locations. From the management module you can prepare the policy. But then you will need to download it on the remote module. If you can simulate the remote network locally you will find it easier to prepare and troubleshoot configurations.

External interface is ethernet and will be connected to a router

For the simulation you will need to change the configuration of your Internet router. You will assign a secondary interface to the router's ethernet interface. This address is the one of the remote site Internet router.

!
interface Ethernet0
ip address 192.168.10.253 255.255.255.0 secondary
ip address 194.191.78.36 255.255.255.224

By extending the number of secondary addresses you can simulate several remote locations at the same time.

External interface is on serial Interface

You will need to simulate the serial connection locally. That kind of serial connection can be of type Cisco HDLC, Frame Relay or PPP. For the simulation you will need to use a local cisco router with an available serial port

If your external interface is serial 0 on a cisco router, you will configure it in DCE mode. For this use Cisco DCE cable. The fact to have a DCE cable put the cisco serial interface in a DCE mode. Then configure the serial interface to give a clock rate to the connection. The NAP cannot work in a DCE mode itself. The nokia V.35/X.21 cable will be connected to the cisco DCE cable, and bothe connected to their respectiv serial ports. The IP address given to the serial interface of the router is the one of the remote site Internet router.


!
interface Serial0
ip address 194.193.192.254 255.255.255.252
clockrate 64000

How to SYNC on Solaris 2.6/cluster patches and FW1-v3.0b 3064 patch

I want to pass on some info about SYNC on Solaris 2.6/cluster patches
and FW1-v3.0b 3064 patch. This is undocumented but a must!

This seems to be crucial on systems where the control module and pfm
are not on the same system...

Our config has three systems. Non-vpn and no NAT just packet
filtering...

control
pfm
pfm

Creating /etc/fw/sync.conf and putkey on the pfm modules is not enough!

Modify the file below table.def and comment out the "#define sync"
command.
Then recompile and download your rule sets to the pfm modules...

This seems to be crucial on systems where the control module and pfm
are not on the same system...so if you have two systems

control/pfm
pfm

you will need to do this table.def mod...

$ more /etc/fw/lib/table.def
#ifndef __table_def__
#define __table_def__

//
// (c) Copyright 1993-1997 Check Point Software Technologies Ltd.
// All rights reserved.
//
// This is proprietary information of Check Point Software Technologies
// Ltd., which is provided for informational purposes only and for use
// solely in conjunction with the authorized use of Check Point Software
// Technologies Ltd. products. The viewing and use of this information
is
// subject, to the extent appropriate, to the terms and conditions of
the
// license agreement that authorizes the use of the relevant product.
//
//
// $Header: /fw/cvs/fw-1/fwlib/table.def,v 1.42.2.20 1998/01/01 08:09:47
ofer Ex
p $
//

// The following #define should be removed to enable FW-1
synchronization
//#define sync

What should I be aware of when upgrading from version 4.0 to 2000

When upgrading from Version 4.0 to Check Point 2000, the Management Station checkbox in the Workstation Properties window will be checked only for the Management Station being upgraded. All other gateways defined on the Management Station will have the Management Station checkbox unchecked by default.

When you upgrade, the $FWDIR/lib/control.map file is replaced. If you have made any changes
to control.map, they will not be preserved in the new control.map, so you must make the same changes in the new version.



Session Authentication Agent — Installing the Version Check Point 2000 Session Authentication Agent does not overwrite the Version 4.0 Session Authentication Agent. You must uninstall the Version 4.0 Session Authentication Agent (using the Control Panel’s Add/Remove Programs applet) and then install the Version Check Point 2000 Session Authentication Agent. Note that the Session Authentication Agent is shut down as part of the uninstallation process, so you must manually restart it (or reboot).



VPN-1/FireWall-1 HP Open View Extension supports Solaris and HP-UX with HP OV version 4.x. HP-UX with HP OV versions 5.x and 6.x is not supported.

 Synchronized VPN/FireWall Modules —

    Synchronized VPN/FireWall Modules must be managed by the same Management Module.
    SecuRemote connections can be synchronized.

Enable Exportable SKIP: If Enable Exportable SKIP (in the Encryption tab of the Properties Setup window) is checked, then if an internal VPN/FireWall Module has Local selected in the Key Manager tab of its SKIP Properties window, you must generate an exportable DH key for it (in its SKIP Properties window). Selective SKIP configuration (that is, some SKIP communications use exportable DH keys and some use non-exportable DH keys) can only be managed in the Rule Base.

Control channel encryption key If you change a Management Server’s control channel encryption key (for example, by using the fw putkey command), then you must restart any ELA proxy that is running on that Management Server. See "Uninstalling VPN-1/FireWall-1" on page 6 for information on how to stop the ELA proxy.

In a High Availability configuration, each VPN/FireWall Module’s license should be issued to its hostid or other unique ("heartbeat" or "configuration IP" interface), since any of the other interfaces can fail.

Do not rename a network object group that is used in the definition of a Logical Server.

Unix platforms — when remote modules are configured using the cpconfig program, if you try to add a new remote module you will not be able to see the list of previously configured modules. However, these modules are still defined and there is no need to reconfigure them. If you do reconfigure them, you must run fw putkey command again for each module.

backward compatibility feature:  If you are using the VPN-1/FireWall-1 Check Point 2000 backward compatibility feature to manage VPN-1/FireWall-1 Version 4.0 SP1 or SP2 FireWall Modules and you use Client Authentication rules, the following workaround must be applied:

a. Edit the file $FWDIR/lib/base.def (where FWDIR specifies the directory in which the VPN-1/FireWall-1 Version 4.0 software or VPN-1/FireWall-1 Check Point 2000 backward compatibility module is installed), replacing the lines:

define pm_prog [(UDPDATA+40+rpc_cred_len+rpc_ver_len),b]
#define pm_prot [(UDPDATA+48+rpc_cred_len+rpc_ver_len),b]

by the lines:

#define pm_prog [68, b]
#define pm_prot [68+8, b]

b. Reinstall the Security Policy on the VPN/FireWall Module.

fw expdate command — This command changes the expiration date of the users in the VPN-1/FireWall-1 users database. Any open GUI Client should be closed before running the command, otherwise the GUI will override the changes made by the command. On NT only, if fw expdate is executed while the Management Server was running, the Management Server should be restarted in order for the command to take effect.

 

What's new in Checkpoint 2000 version 4.1

    1)High Availability — Two or more VPN/FireWall Modules can be configured so that each one acts as a backup to the others. Additionally, the VPN/FireWall Modules can be synchronized so that connections will not be lost when a VPN/FireWall

    2)Desktop Policy Verification — Policy Servers now maintain open connections with SecureClients and are immediately notified when a SecureClient is re-configured. Both Session Authentication and Client Encrypt rules can be applied only when a SecureClient is properly configured.
    3)SecuRemote
        i)The Secure Domain Logon feature enables Windows NT SecuRemote users to securely log on to a domain controller using both LAN and dial-up connections.
        ii)SecuRemote Clients can be configured to automatically update a site’s topology either when starting SecuRemote or just before the key exchange with that site.
        iii)SecuRemote Clients can be configured to automatically check the availability of a newer version of SecuRemote Client software before connecting to a site.
        iv)SecuRemote Clients can be pre-configured with a partial site topology to reduce exposure of sensitive network information. The first time the SecuRemote Client connects to a site, the user will be given the opportunity to download the complete topology over the authenticated connection.
        v)A smaller SecuRemote (Thin Client) Client installation file set (without the certificate functionality) is available ("Thin Client")  

    4)Hybrid Mode — VPN-1/FireWall-1 Hybrid Mode authentication extends IKE, enabling it to use any authentication method supported by VPN-1/FireWall-1. 

   5)Intel RNG — VPN-1/FireWall-1 and SecuRemote support the Intel RNG (pseudo random number generator) hardware for Windows NT 4.0, Windows 98, Windows 95 (OSR2 or later or Windows 95 with IE 3.02 or later). 

    6)Remote Licensing Management — This feature enables the system administrator to manage VPN-1/FireWall-1 licenses on remote VPN/FireWall Modules from the Management Station. 

    7)Malicious Activity Detection — VPN-1/FireWall-1’s Malicious Activity Detection (MAD) feature provides a mechanism for detecting intrusion attempts or other suspicious events and notifying the system administrator by an alert or email message. 

How to debug IKE encryption problems

If the IKE tunnel cannot be established have a look in the FireWall-1 logviewer. 
If the logviewer is not helpful, use the advanced IKE debugging option in FireWall-1:

Set the appropriate debug variable:

setenv FWISAKMP_DEBUG=1 (for FireWall-1 4.0)
setenv FWIKE_DEBUG=1 (for FireWall-1 4.1)

(On NT firewalls, use 'set' instead of setenv)

Rerun the FireWall-1 daemon (do: 'fwstop' and 'fwstart'). 

All subsequent IKE negotiations will be dumped in the file ISAKMP.log in FireWall-1 4.0 
or IKE.elg in FireWall-1 4.1 (both in $FWDIR/log.

An advanced IKE user can use this file to help detect IKE problems. This file should be sent whenever contacting Check Point