atrg nokia appliance

8/2/2019 ATRG Nokia Appliance

1/45

Check Point

VPN-1 Appliance

Advanced Technical Reference Guide

Check Point 2000
http://iii.checkpoint.com/support/training/atsg41/vpn1appliance/


2/45

1

Contents:

Preface ...........................................................................................................................................................3

Scope........................................................................................................................................................3Links to SecureKnowledge .......................................................................................................................3Who should use this Guide.......................................................................................................................3

How to obtain the latest version of this Guide ..........................................................................................3Feedback Please! .....................................................................................................................................3

Introduction ...................................................................................................................................................4

IPSO The VPN-1 Appliance Operating System .......................................................................................5

IPSO design more secure .....................................................................................................................5IPSO File System Layout..........................................................................................................................6IPSO information gathering utility ipsoinfo ...........................................................................................6

Upgrading a VPN-1 Appliance .....................................................................................................................7

Before You Begin......................................................................................................................................7Other Considerations................................................................................................................................7Begin the Upgrade....................................................................................................................................7Notes.......................................................................................................................................................14Upgrading VPN-1/FireWall-1 Packages .................................................................................................16

VPN-1 Appliance Common issues ............................................................................................................17

Equal cost multipath with VPN-1/FireWall-1 using static routing (preventing asymmetric paths)..........17Allowing routing protocols (RIP, OSPF, IGRP, and BGP) through VPN-1/FireWall-1 ...........................18Monitoring memory and CPU utilization .................................................................................................19Configuring the default filter on VPN-1 Appliance ..................................................................................21Receiving the error message : "FW_IPADDR: cannot get my IPADDR" ...............................................21How to set a VPN-1 Appliance back to factory defaults? .......................................................................21How to enable Network Voyager access to a VPN-1 Appliance ............................................................21Cannot connect to VPN-1 Appliance box with web browser to use Voyager.........................................21Apache Server has security issues when running on the VPN-1 Appliance ..........................................21

How to determine which fw processes are running on a VPN-1 appliance box?...................................21How to add a static ARP entry on boot-up on the VPN-1 Appliance or Nokia products ........................21How to improve the process time of fw logexport...................................................................................21With Apache on VPN-1/FireWall-1, port 80 is available by default to any source IP address ...............22How to move Network Voyager off default TCP port 80.........................................................................22Existing security policy will not allow GUI client connection ...................................................................22How to make changes to files on the VPN-1 Appliance when the partition is mounted as Read-Only ..22How to reset the boot password on a VPN-1 Appliance ........................................................................22How to generate a core dump on a VPN-1 appliance and what is the location of the core files............22How to secure the Network Voyager (HTTP) access with SSH? ...........................................................22How to create a cron job on VPN-1 Appliance to automate `fw logswitch` ............................................22Where is the IPSO system message file located? .................................................................................22How to set the domain name on VPN-1 Appliance? ..............................................................................22

High Availability VRRP Monitored Circuit on IPSO 3.1 and later........................................................23

A summary of differences between VRRP v2 and Monitored Circuits ...................................................23VRRP Configuration ...............................................................................................................................24Solving Common VRRP Problems .........................................................................................................28

VPN-1 Appliance Command Line Interface..............................................................................................31

I. Controlling IP forwarding on a VPN-1 Appliance.................................................................................31II. Installing new images/packages using the newimage and newpkg commands.............................31III. Using the tcpdump utility to view packets on an interface.................................................................32


3/45

VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000 2

IV. Providing routing diagnostics using the iclid command...................................................................36V. ping, netstat and traceroute...........................................................................................................37VI. route.................................................................................................................................................37VI. Using the ipsrd command to troubleshoot network routing problem ...............................................37VII. Using the ipsctl command line to set kernel variables....................................................................38

Further information.....................................................................................................................................40

Check Point Support Information............................................................................................................40Nokia support Information ......................................................................................................................44


4/45

Preface IPSO 3.0.x


Preface

Scope

The VPN-1 Appliance Advanced Technical Reference Guide is intended to help the System Administratorsresolve common problems and implement complex features.

The guide contains information gathered both from Supports real-world experience in assisting customers.

Every chapter was written by a specialist in the field.

This guide does not duplicate the User Guides or Courseware. It either covers those topics not found in the User

Guides, or expands on them.

The VPN-1 Appliance Advanced Technical Reference Guide is updated to version 4.1 SP1 (Check Point 2000).

Links to SecureKnowledge

This guide contains many links to solutions in the Check Point SecureKnowledge database

http://support.checkpoint.com/kb/index.htmland other places in the Check Point Premium Support sitehttp://www.checkpoint.com/support/technical/.

SecureKnowledge is a self-service database of technical information to help you diagnose and solve installation,

configuration, and upgrade problems with Check Point Software products.

To use SecureKnowledge you must be authenticated using your Support username and password. If you are not

already authenticated, you will be required to do so the first time you click on a link.

Who should use this Guide

This guide is written for people who provide Technical Support to System Administrators maintaining network

security and Virtual Private Networks.

It assumes: A basic understanding and a working knowledge of VPN-1 Appliance

Familiarity with the relevant User Guides

How to obtain the latest version of this Guide

The latest version of this Advanced Technical reference Guide and the other guides in the series, can be found

at http://www.checkpoint.com/support/technical/documents/

This guide is freely available to anyone who is registered to the (password protected) Check Point Technical

Services Premium Support site http://www.checkpoint.com/support/technical/index.html.

Feedback Please!Is the information is this guide useful?

Did you find what you were looking for?

What would you like to see in this guide?

Is there too much detail or not enough?

We in Check Point Support would love to hear what you think of this guide. Please write to

[email protected]
http://support.checkpoint.com/kb/index.htmlhttp://www.checkpoint.com/support/technical/http://www.checkpoint.com/support/technical/http://www.checkpoint.com/support/technical/documents/http://www.checkpoint.com/support/technical/index.htmlhttp://www.checkpoint.com/support/technical/index.htmlmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackhttp://www.checkpoint.com/support/technical/index.htmlhttp://www.checkpoint.com/support/technical/documents/http://www.checkpoint.com/support/technical/http://support.checkpoint.com/kb/index.html


5/45

Introduction IPSO 3.0.x


Introduction

The VPN-1 Appliance allows organizations to deploy a single, integrated network security solution, providing

secure Internet communications and access control for networks ranging from carrier-class to regional-office

environments. The VPN-1/FireWall-1 packages are built into the platform and are easy and fast to install and

manage. The VPN-1 Appliance can act both as a VPN/FireWall module and a management server. For mostversions it is not recommended to place the VPN/FireWall module and a management server on the same

machine. The latest releases (IPSO 3.3 and VPN-1/FireWall-1 4.1 SP2) include modifications to the startup

scripts so that the VPN-1 Appliance can work properly as a Management Server, since it has the disk capacity

(15 GB) to store logs files.

The VPN-1 Appliance is a tool to create Virtual Private Networks (VPNs), enabling secure connectivity for

remote sites and users. By implementing the High Availability feature, VPN-1 Appliance supplies safe

connectivity for mission-critical applications that requires continuous network availability. Standard on all

VPN-1 Appliance platforms, Virtual Router Redundancy Protocol (VRRP) enables load-sharing and active

redundancy between two or more VPN-1 Appliance systems, ensuring that access to the network is always

available.

Note: This document contains a number of links to Resolutions on the Nokia Support site

http://support.nokia.com. See Nokia Support Site Access on page 44 for access details.
mailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackmailto:[email protected]?subject=ATRG%20feedbackhttp://support.iprg.nokia.com/http://support.iprg.nokia.com/http://support.iprg.nokia.com/


6/45

IPSO The VPN-1 Appliance Operating System IPSO 3.0.x


IPSO The VPN-1 Appliance Operating System

IPSO is a customized UNIX routing operating system (OS) that began as a version of FreeBSD 2.1.x. FreeBSD

2.2.6 is used for todays IPSO SDK. Since IPSO has undergone many changes to customize and provide it as a

hardened OS there is no version of FreeBSD that maps directly to it.

For those new to the FreeBSD and UNIX, a good overview is provided at

http://www.freebsd.org/tutorials/new-users/index.html. A good reference for the FreeBSD commands included

in IPSO is http://www.freebsd.org/cgi/man.cgi?manpath=FreeBSD+2.2.6RELEASE.

Running other FreeBSD software applications is not normally possible. Even if an application does install and

run, any system modified in this manner isnt supported because it hasnt undergone the necessary QA testing.

Please contact your sales representative to see if it is possible to add this functionality. Check Point will then

work with Nokia to port and test the application and provide support for it. Nokia has made some utilities

available in their Resolution 1783 that can be found on http://support.nokia.com

IPSO design more secure

From a design standpoint, VPN-1 Appliance started with no binaries or libraries and then added what was

needed with an eye toward a compact and secure system.

The inetd.conf file starts empty, and services must explicitly be added via Network Voyager, the web

interface.

Sendmail is included, but only for outbound email alerts that originate on the platform. It cannot be used as

a mail relay and is not allowed to bind to TCP port 25. For this reason, there is no security risk in using this

application for email alerts. Both IPSO and VPN-1/FireWall-1 can take advantage of this.

There are no Berkeley r commands (rsh, rlogin, rexec, etc.). These are known to be insecure.

There is no exportable file system (such as NFS), which can be a security risk.

There are no remote-user information daemons and services, such as finger, whom, and talk.

There is no development environment, which stops any intruders from building binaries.

There are no small services (chargen, echo, etc.) by default. The administrator can however enable

them

There is no BIND (DNS server), or dependence on external DNS service.

There is no news server, printing, NIS, POP, IMAP, or X Window System.

There is no extraneous CGI program on the system.
http://www.freebsd.org/tutorials/new-users/index.htmlhttp://www.freebsd.org/tutorials/new-users/index.htmlhttp://www.freebsd.org/cgi/man.cgi?manpath=FreeBSD+2.2.6-RELEASEhttp://www.freebsd.org/cgi/man.cgi?manpath=FreeBSD+2.2.6-RELEASEhttp://support.iprg.nokia.com/http://support.iprg.nokia.com/http://www.freebsd.org/cgi/man.cgi?manpath=FreeBSD+2.2.6-RELEASEhttp://www.freebsd.org/tutorials/new-users/index.html


7/45

IPSO The VPN-1 Appliance Operating System IPSO 3.0.x


IPSO File System Layout

Directory Contains

/opt Software packages, such as Check Point VPN-1/FireWall-1, Websense, OpenService, etc.

/varIPSO admin home directory

/config IPSO configuration file. The file is /etc/active. This is a symbolic link to /config/db. IPSO

rebuilds /etc from the master configuration file on boot-up. /config/active is the currently

active IPSO configuration set.

/config is originally linked to /config/db/active. Network Voyager may be used to save

the current configuration set to one of a unique name, also saved in /config/db. An IPSOconfiguration set contains all of the configuration information for a VPN-1 Appliance. Smallenough to fit onto a floppy diskette, it can completely restore the configuration on a newlyinstalled platform.

/image Kernel image. The IPSO image is an entire kernel release. When a new image is loaded with thenewimage i command (for further information see II. Installing new images/packages using

the newimage and newpkg commands), it will be installed here. You can then switch to thenew image or back to old at any time, using the manage installed packages link in Network

Voyager.

IPSO information gathering utility ipsoinfo

For more detailed information, see the SecureKnowledge solution How to get debug info to Support using the

ipsoinfo utility (ID: 3.0.142473.2194045 )

ipsoinfo is a shell script included in IPSO 3.2.x and above which includes an fwinfo, IPSO config files,

core files, and more. The shell script will write everything to stdout, therefore it is necessary to redirect the

output of this shell script to a file.

The following command will create ipsoinfo.txt.gz, which gunzip will readily uncompress, creating

ipsoinfo.txt, which is an ASCII file containing all of the output of the commands executed in the shell

script.# ipsoinfo | gzip -9 -c > ipsoinfo.txt.gz

You do not need to gzip anything. The resulting output is written to /var/admin and can be sent to Support

without modification.
http://support.checkpoint.com/support/publisher.asp?id=3.0.142473.2194045http://support.checkpoint.com/support/publisher.asp?id=3.0.142473.2194045http://support.checkpoint.com/support/publisher.asp?id=3.0.142473.2194045http://support.checkpoint.com/support/publisher.asp?id=3.0.142473.2194045


8/45

Upgrading a VPN-1 Appliance IPSO 3.0.x


Upgrading a VPN-1 Appliance

This section lists the steps necessary to successfully upgrade the VPN-1 Appliance from one version of the

IPSO operating system to another, taking into account the versions of packages such as VPN-1/FireWall-1 that

are supported on each IPSO version. The assumption is you wish to upgrade to the latest version of both IPSO

and VPN-1/FireWall-1.

Although the steps listed may appear to be out of order, there are good reasons for first upgrading

VPN-1/FireWall-1 and then IPSO before finally upgrading VPN-1/FireWall-1 to the desired version. This is

because there is no direct upgrade path from all versions of VPN-1/FireWall-1 or from all versions of IPSO, and

not all versions of VPN-1/FireWall-1 are compatible with all versions of IPSO.

Before You Begin

Before starting the upgrade, you must obtain the VPN-1/FireWall-1 license for the software version you intend

to run. The licenses have changed between versions 3.x and 4.x. Allow yourself at least one week between

requesting a 4.x license using a 3.x certificate key (or a 4.1 license with a 4.0 certificate key), and the time you

intend to perform an upgrade.

If you can, set up an Anonymous FTP server that can be used to serve the binaries to the platform during an

installation or an upgrade. The newimage utility offers one the choice of retrieving an IPSO image from an

anonymous FTP server or from an FTP server using a user name and a password. If you need to update a large

number of platforms, this option makes it easier.

Other Considerations

1. If you have doubts about your ability to perform the steps outlined, make plans for experienced technical

assistance to be on-site during the process.

2. If you have any questions regarding the information in this resolution, obtain clarification of any issues that

you may have from your support representative well in advance of the time you intend to execute these

steps. It is not possible for a customer support engineer to walk through the steps over the phone.

3. Do not proceed until you have all relevant licenses in hand, including the ones for the software versions

you intend to upgrade. If, for any reason, you wish to downgrade to an earlier version of

VPN-1/FireWall-1, you should be able to reinstall the VPN-1/FireWall-1 license, even if you have a good

backup of the $FWDIR/conf/fw.license file.

4. Upgrade the VPN-1/FireWall-1 Management Module host first, and verify that it can download the security

policy to the remote packet-filter module (PFM) platforms and receive log information from them. You

may then proceed to upgrade each PFM.

5. If you are currently running VRRP v2, you may wish to migrate your configuration to Monitored Circuits.

See Migrating from VRRP v2 to Monitored Circuits on page 26 for more details.

Begin the Upgrade

Pick the heading that is appropriate for the version of IPSO you are currently on and move forward from there.

Note that since various parts of the upgrade involve similar and/or lengthy steps, you will often be referred to

items in the Notes on page 14.

IPSO 3.0.x

It is not possible to upgrade directly from IPSO 3.0.x past version IPSO 3.1.2. The first version of IPSO that can

be safely upgraded to IPSO 3.2 is IPSO 3.1.3. The earliest versions of VPN-1/FireWall-1 that can run on IPSO


9/45

Upgrading a VPN-1 Appliance IPSO 3.0.x


3.1.x is FireWall-1 3.0b 3078plus. This is the only 3.0 version of FireWall-1 that can be safely upgraded to 4.0

and the only version of VPN-1/FireWall-1 4.0 that does this correctly is 4.0 SP1. Therefore, upgrade to IPSO

3.1.2 and VPN-1/FireWall-1 4.0 SP1.

Perform the following steps:

1. Upgrade FireWall-1 to 3.0b 3078plus for IPSO 3.0.x

Depending on your existing configuration, this may not be necessary. To perform this upgrade, downloadthe appropriate tar file, tar extract it, and run the enclosed " ipsofwpatch" script.

2. Backup Configuration Information

See Backup Configuration Information on page 15

3. Boot off IPSO 3.1.x boot floppy, installing IPSO 3.0.x from CD or FTP

The disk partitioning in IPSO 3.0.x was inefficient. IPSO 3.1 and later have more efficient disk partitioning

schemes. In order to take advantage of this new scheme, the system must be reinstalled from scratch using

an IPSO 3.1.x (or later) boot floppy. We are reloading IPSO 3.0.x so that we can perform a proper upgrade

to IPSO 3.1.x.

4. Restore Existing Configuration

As noted in Backup Configuration Information on page 15, tar-extract the file into a temporary directoryand copy the files to their correct locations.

5. Rename Existing Active File to machine-name_30x

See Managing IPSO Configuration Sets on page 15 for more details.

6. Install IPSO 3.1.2

This is the latest version of IPSO that is known to upgrade an IPSO 3.0.x system successfully. Use the

newimage command to load this ipso.tgz file into the system.

7. Reboot, but do not activate any packages, as you will need to upgrade FireWall-1 first.

8. Upgrade FireWall-1 3.0b p3078plus for IPSO 3.0.x to VPN-1/FireWall-1 4.0 SP1.

See


10/45

Upgrading a VPN-1 Appliance IPSO 3.1, 3.1.1, and 3.1.2


Upgrading VPN-1/FireWall-1 Packages on page 16 for more details.

9. (Optional) Install ssh server

IPSO 3.1 and later includes a ssh client and server. This allows you to have an encrypted telnet-like session

between you and your VPN-1 Appliance. Customers located in the US and Canada can download this

directly from http://www.checkpoint.com/cgi-bin/download.cgi. For customers in other countries, refer to

Resolution 1348. on the Nokia Support site

10. Move Static ARPs out of/var/etc/rc.local to Network Voyager.

IPSO 3.0.x had no facility for static ARP entries in Network Voyager. In IPSO 3.1, these are done in

Network Voyager. Furthermore, ARPs from /var/etc/rc.local are not supported in IPSO 3.1 or

later. You will have to manually add all the ARPs listed in /var/etc/rc.local to Network Voyager

and remove the entries from /var/etc/rc.local (including the prerequisite sleep command).

11. Activate Packages and Reboot.

You should now have a platform running VPN-1/FireWall-1 4.0 SP1 and IPSO 3.1.2. Continue with the next

section.

IPSO 3.1, 3.1.1, and 3.1.2

To upgrade to a higher version than IPSO 3.1.2, you must first upgrade your IPSO platform to IPSO 3.1.3. Note

that either FireWall-1 3.0b 3078plus or VPN-1/FireWall-1 4.0 (up to Service Pack 4) is supported under IPSO

3.1.x.

1. Upgrade Boot Manager on IP330 and IP650 to IPSO 3.1.3 Boot Manager

See Boot Manager Upgrade on page 14.


Use the newimage command to load this ipso.tgz file into the system.

You should now have a platform running IPSO 3.1.3. Continue with the next section.

IPSO 3.1.3, 3.1.4Either of these versions can be successfully upgraded to IPSO 3.2. Note that either FireWall-1 3.0b 3078plus or

VPN-1/FireWall-1 4.0 (up to Service Pack 4) is supported under IPSO 3.1.x. However, IPSO 3.2 does not

support FireWall-1 3.0. To upgrade to IPSO 3.2, we must first upgrade VPN-1/FireWall-1 to 4.0.

1. Upgrade FireWall-1 to 4.0 SP1 (see
http://www.checkpoint.com/cgi-bin/download.cgihttp://www.checkpoint.com/cgi-bin/download.cgihttp://support.nokia.com/http://support.nokia.com/http://www.checkpoint.com/cgi-bin/download.cgi


11/45

Upgrading a VPN-1 Appliance IPSO 3.1.3, 3.1.4


Upgrading VPN-1/FireWall-1 Packageson page 16).

Depending on your existing configuration, this may not be necessary.

2. Upgrade VPN-1/FireWall-1 to 4.0 SP4 (see


12/45

Upgrading a VPN-1 Appliance IPSO 3.1.5, 3.2


Upgrading VPN-1/FireWall-1 Packages on page 16).


3. Upgrade Boot Manager on IP330 and IP650 to IPSO 3.2 Boot Manage (see Boot Manager Upgrade on

page 14).

4. Rename Existing Active File to machine-name_31x


5. Install IPSO 3.2.

Use the newimage -k command to load the ipso.tgz file into the system. The -k command-line interface

parameter ofnewimage must be used to keep the currently enabled packages running through the reboot after

IPSO 3.2 has been installed.

At this point, the platform should be running IPSO 3.2 and VPN-1/FireWall-1 4.0 SP5. This method ensures

that the system boots with VPN-1/FireWall-1 running with the last installed security policy. If you upgrade

FireWall-1 from version 3.0 to 4.0, you will have to re-install the security policy from your management

station. Continue with next step to upgrade to IPSO 3.2.1.

IPSO 3.1.5, 3.2These versions can be successfully upgraded to IPSO 3.2.1. All versions of VPN-1/FireWall-1 4.0 and

VPN-1/FireWall-1 4.1 SP0, and 4.1 SP1 are supported in IPSO 3.2 and 3.2.1. If still running FireWall-1 3.0, we

must first upgrade to VPN-1/FireWall-1 4.0 SP1.

1. Upgrade FireWall-1 to 4.0 SP1 (see


13/45



Upgrading VPN-1/FireWall-1 Packages on page 16)


2. Upgrade VPN-1/FireWall-1 to 4.0 SP5 (see


14/45





3. Upgrade VPN-1/FireWall-1 to 4.1 (see


15/45

Upgrading a VPN-1 Appliance Boot Manager Upgrade



You can upgrade to either 4.1 Base or 4.1 Service Pack 1. You can skip this step if you do not have a

license for 4.1.

4. Upgrade Boot Manager on IP330 and IP650 to IPSO 3.2.1 Boot Manager (see Boot Manager Upgrade

below).

If running on the IPSO 3.2 boot manager, this is not required unless you plan to use a disk bigger than 8Gbyte. This step can be performed after the installation of IPSO 3.2.1 if desired.

5. Rename Existing Active File to machine-name_31x or machine-name_32



Use the newimage -k command to load the ipso.tgz file into the system. The -k CLI parameter of

newimage must be used to keep the currently enabled packages running through the reboot after IPSO

3.2.1 has been installed.

At this point, the platform should be running IPSO 3.2.1 and the latest version of VPN-1/FireWall-1. This

method ensures that the system boots with VPN-1/FireWall-1 running with the last installed security policy. If

you upgrade FireWall-1 from version 3.0 to 4.0 or from 4.0 to 4.1, you will have to re-install the security policy

from your management station.

Downgrade Warnings: Once you upgrade to IPSO 3.2.1, you can only downgrade to IPSO 3.2. If you need to

downgrade to IPSO 3.1.5 or earlier, you must completely reformat your system and reinstall it from scratch. If

you wish to switch back to IPSO 3.2, you must first downgrade your boot manager to IPSO 3.2 before

switching to IPSO 3.2.

Notes

This is a list of some of the issues referenced above as well as few other points of interest.

Boot Manager Upgrade

Problem

An IPSO 3.2.1 boot manager is not compatible with IPSO 3.2 or earlier. The boot manager distributed with

IPSO 3.2 is compatible with IPSO 3.1.5 or earlier. The first boot manager upgrade was introduced with the

release of IPSO 3.1.3 to fix a problem on the IP650 with hot swappable interface cards.

Solution

If you intend to be able to downgrade to a previous version of IPSO, then you should have each instance of the

boot manager in the /etc directory. Then, the process of downgrading from IPSO 3.2 to IPSO 3.1.5 is

1. Boot single-user

2. Install the IPSO 3.1.5 boot manager

For VPN-1 Appliance IP650, execute/etc/upgrade_bootmgr wd1 /etc/bootflash.bin

For VPN-1 Appliance IP330, execute/etc/upgrade_bootmgr wd0 /etc/bootflash.bin

mount /config

3. Move /image/current to point to IPSO 3.1.5

4. Reboot machine


16/45

Upgrading a VPN-1 Appliance Managing IPSO Configuration Sets


Managing IPSO Configuration Sets

Problem

The IPSO configuration set file format changed between 3.0.x and 3.1.x, and again between 3.1.x and 3.2.x.

Switching back and forth between these releases groups can be problematic.

Solution

You can name a configuration set anything you want, but it should, at least, include the system name and the

version of IPSO with which it is associated:

fm1_304 - If running IPSO 3.0.4

fm1_315 - for IPSO 3.1.5

fw1_320 - for IPSO 3.2.0

IPSO configuration set files are small, you can have dozens of them while utilizing less than 1 MB of disk

space. The names can be 255 characters, so get as explicit as you want.

This does not imply that switching back and forth between the major versions is not without trouble:

3.2.x3.0.x is not supported. You are better off reinstalling 3.0.x and restoring the configuration files

from backup.

3.2.0 3.1.5 is supported if you supply a valid 3.1.x configuration file.

3.2.1 3.1.x is not supported. You are better off reinstalling 3.0.x and restoring the configuration files

from backup.

3.1.x 3.0.x is not supported. You are better off reinstalling 3.0.x and restoring the configuration files

from backup.

Backup Configuration Information

ProblemThe configuration files for one VPN-1/FireWall-1 package are likely to be in a different directory path than

another version of VPN-1/FireWall-1. This is only an issue if one chooses to restore, for example, the

configuration files from VPN-1/FireWall-1-strong.v4.0.SP1 into the directories belonging to

VPN-1/FireWall-1-strong.v4.0.SP3

Solution

Refer to Resolution 718 on the Nokia Support site for tips on backing up files from IPSO systems prior to

version 3.2. IPSO 3.2 has a Backup and Restore feature in Network Voyager. This feature enables one to

backup IPSO and VPN-1/FireWall-1 configuration files, log files, and the contents of the /var/admin

directory. The gzipped tar file is saved in /var/backup and Network Voyager enables you to retrieve this

backup file to your local system via HTTP.

When it comes to restoring saved configuration files, you may have to extract them to a temporary directory and

then copy them over to their destination
http://support.nokia.com/http://support.nokia.com/


17/45

Upgrading a VPN-1 Appliance Backup Configuration Information


Upgrading VPN-1/FireWall-1 Packages

The newpkg utility must be used without any command-line parameter when performing an upgrade in order

for the process to execute the upgrade script. Network Voyager's Manage Installed Packages add-package utility

does not yet do this, nor does any other execution of newpkg with a CLI parameter (to learn more about the

newpkg utility, please refer to II. Installing new images/packages using the newimage and newpkgcommands on page 31. Reboot after loading. If the upgrade is from version 3.x to 4.0, run fwconfig to enter

your new license.

Not all versions of VPN-1/FireWall-1 are compatible with all versions of IPSO. The following table shows

which versions of VPN-1/FireWall-1 are compatible with versions of IPSO:

IPSO Version Compatible VPN-1/FireWall-1 Version(s)

3.0.x 3.0b 3078plus1

and earlier

3.1.x 3.0b 3078plus1, 4.0 Service Packs 1, 2, and 4

3.2.x All 4.0 Service Packs, 4.1 Base2, and 4.1 Service Pack 1

2

3.3 All 4.1 Service Packs2

1There are different builds for IPSO 3.0.x and IPSO 3.1.x

2There are different builds for IPSO 3.2.x and IPSO 3.3

There are also restrictions on the VPN-1/FireWall-1 versions that can be upgraded from previous versions of

VPN-1/FireWall-1.

VPN-1/FireWall-1 upgrades the following VPN-1/FireWall-1 versions

3.0b 3078plus All previous 3.0b versions

4.0 Service Pack 1 3.0b 3078plus

4.0 Service Pack 5 Any previous 4.0 Service Pack

4.1 Base or 4.1 Service Pack 1 4.0 Service Pack 3 and later


18/45

VPN-1 Appliance Common issues Scenario #1 (Without NAT)


VPN-1 Appliance Common issues

Equal cost multipath with VPN-1/FireWall-1 using static routing

(preventing asymmetric paths)FireWall-1 does not synchronize its state tables fast enough for a return packet to take a second route through a

second VPN-1/FireWall-1 that is synchronized. This synchronization interval should not be changed since this

will cause a performance hit.

Therefore, a solution that allows for deterministic routes is in order to alleviate the problem of asymmetric.

The following scenarios will prevent equal cost multi-path routes from causing asymmetric.

Scenario #1 (Without NAT)

This scenario shows how to setup static routes and SRC/DST hashing on an internal and external router in order

to keep the paths the same, while entering and exiting the network.

On the external Router

Configure two Static routes that send the same destination address to both Firewalls as the gateway address. In

the example, we would add a static route going to 10.0.0.0 and the gateways would be 192.168.1.1 and

192.168.1.2 with equal metrics.

Configure the External Router to use SRC/DST hashing in Network Voyager by going to: Config Routing

Options (This should be default)

Middle FireWall Pair

Make sure you number your external and internal interfaces in ascending order. This means that the first

Firewall's last octet should contain a lower numbered IP than that of the second Firewall's. As the example

shows, the external and internal numbers are number consecutively ascending.

On the internal Router

The internal router must be configured with two gateways on the default route, one for each Firewall's internal

address. In the example shown the default route should be configured to gateway to 10.0.1.1 and 10.0.1.2 with

equal metrics.

Configure the Internal Router to use SRC/DST hashing in Network Voyager by going to: Config Routing

Options (This should be default)

This configuration is now complete, and packets entering and leaving the network from different sources should

be load sharing and also have the same path into the network as out, thus skirting the issue of asymmetric

connections.

Scenario #2 (With NAT, and only in IPSO 3.3)This scenario shows how to set up static routes with SRC hashing on the outside, and DST hashing on the inside

router, in order to keep the paths the same while entering and exiting the network.

On the external Router

Configure two Static routes that send the same destination address to both Firewalls as the gateway address. In

the example, we would add a static route going to 10.0.0.0 and the gateways would be 192.168.1.1 and

192.168.1.2 with equal metrics.


19/45

VPN-1 Appliance Common issues I. Enabling RIP


Configure the External Router to use SRC hashing in Network Voyager by going to: Config Routing Options

(This should be default)

Middle FireWall Pair

Make sure you number your external and internal interfaces in ascending order. This means that the first

Firewall's last octet should contain a lower numbered IP than that of the second Firewall. As the example

shows, the external and internal numbers are numbered ascending. For example, ". 1" and ". 2".

On the internal Router

The internal router must be configured with two gateways on the default route, one for each Firewall's internal

address. In the example shown the default route should be configured to gateway to 10.0.1.1 and 10.0.1.2 with

equal metrics.

Configure the Internal Router to use DST hashing in Network Voyager by going to: Config Routing Options

(This should be default)

This configuration is now complete, and packets entering and leaving the network from different sources should

be load sharing and also have the same path into the network as out, thus skirting the issue of asymmetric

connections.

Allowing routing protocols (RIP, OSPF, IGRP, and BGP) throughVPN-1/FireWall-1

If routing does not function when VPN-1/FireWall-1 is enabled but works when the VPN-1/FireWall-1 software

is disabled, you must modify the rule base to allow routing protocols to the FireWall.

I. Enabling RIP

A. RIP version 1

RIP runs over UDP port 520. It sends and receives all messages on this port; all messages are sent to the local

broadcast address. To enable RIP, add a rule to allow all the neighbours of a FireWall to send messages to UDPport 520 on the local broadcast network. RIP is a predefined service in the VPN-1/FireWall-1 GUI.

Neighbor 1 -- Network 1 Broadcast -- RIP -- Accept



B. RIP version 2

RIPv2 can use either the RIPv1 broadcast transport mechanism or a multicast transport (RIP2-

ROUTERS.MCAST.NET, 224.0.0.9).

To enable RIPv2 in multicast mode, create a network object for the multicast address with a netmask of

255.255.255.255, and add the following rules to your rule base:

Neighbors -- RIP2-ROUTERS.MCAST.NET -- RIP -- Accept

Note that RIP can also be enabled via the Rule Base Properties screen.

II. Enabling OSPF

1. Create a workstation object of 224.0.0.5 and call it OSPF-ALL.MCAST.NET

2. Create another workstation object of 224.0.0.6 and call it OSPF-DSIG.MCAST.NET


20/45

VPN-1 Appliance Common issues III. IGRP


3. Then create the following rule:

Source Destination Service Action Track

Any OSPF Objects FireWall OSPF Accept Don't Log

III. IGRP

Like OSPF, IGRP runs on top of IP; IGRP is IP protocol 9. IGRP is a predefined service in the

VPN-1/FireWall-1 GUI. You should define a group of neighbor routers that participate in IGRP routing, and

accept that service to the FireWall:

Neighbors -- firewall -- igrp -- Accept

IV. BGP

BGP runs over TCP port 179. One TCP connection is opened for each BGP peer. Each peer must be allowed to

send BGP messages over its connection to the FireWall.

BGP is not defined as a service in the VPN-1/FireWall-1 GUI. It must be added as a TCP service that uses port

179. BGP peers should also be grouped together to allow them as a group with the following rule:

Peers -- firewall -- bgp -- Accept

V. Eitherbound Inspection

If Eitherbound inspection is required, rules must be added to allow outbound routing advertisements as well as

the inbound rules described above.

Monitoring memory and CPU utilization

Below is a script that can be used to check resources on an IPSO unit running Check Point VPN-1/FireWall-1.

This is helpful in finding out the load on the system. VI editor test and paste in the script below (Do this in

var/admin). Run the script with an argument, which will be the file that this information is sent to. If you

want to use stdout, use /dev/tty as the file.

Note the commented bits are used to grab specific interface statistics from ipsctl, which aren't usually

necessary and can be verbose.


21/45

VPN-1 Appliance Common issues V. Eitherbound Inspection


#!/bin/sh

OUTFILE=$1

# IF1=eth-s1p2

# IF2=eth-s1p3

touch $OUTFILE

while [ 1 ]; do

echo "===============================" >> $OUTFILE

date >> $OUTFILE

echo "===============================" >> $OUTFILE

echo >> $OUTFILE

echo "# fw tab -s" >> $OUTFILE

echo >> $OUTFILE

fw tab -s >> $OUTFILE

echo >> $OUTFILE

echo >> $OUTFILE

echo "# fw ctl pstat" >> $OUTFILE

echo >> $OUTFILE

fw ctl pstat >> $OUTFILE

echo >> $OUTFILE

echo >> $OUTFILEecho "# ps auxw" >> $OUTFILE

echo >> $OUTFILE

ps auxw >> $OUTFILE

echo >> $OUTFILE

echo >> $OUTFILE

echo "# vmstat -c 5" >> $OUTFILE

echo >> $OUTFILE

vmstat -c 5 >> $OUTFILE

echo >> $OUTFILE

echo >> $OUTFILE

echo "# netstat -m" >> $OUTFILE

echo >> $OUTFILE

netstat -m >> $OUTFILE

echo >> $OUTFILE

echo >> $OUTFILE

echo "# vmstat -i" >> $OUTFILE

echo >> $OUTFILE

vmstat -i >> $OUTFILE

echo >> $OUTFILE

echo >> $OUTFILE

# echo "# ipsctl -a (lots of options)" >> $OUTFILE

# echo >> $OUTFILE

# ipsctl -a ifphys:$IF1:errors ifphys:$IF1:stats ifphys:$IF1:dev

ifphys:$IF2:errors \

# ifphys:$IF2:stats ifphys:$IF2:dev net:ip:rxstats net:ip:txstat

net:ip:misc:stats \

# net:ip:frag:stats >> $OUTFILE# echo >> $OUTFILE

# echo >> $OUTFILE

sleep 30

done


22/45



Configuring the default filter on VPN-1 Appliance

You don't edit the default filter on an VPN-1 Appliance. Unlike Solaris, upon which you may run fwconfig

and select a default filter to either block all traffic or only incoming traffic, the VPN-1 Appliance have a single

default filter which only blocks incoming traffic.

This is necessary when the VPN-1 Appliance needs to connect to an external management module host in order

to log and to fetch a security policy. In truth, the other filter is not needed at all. IP forwarding is not enabled

until fwstart executes, and the filter blocks incoming traffic.

Receiving the error message : "FW_IPADDR: cannot get myIPADDR"

SecureKnowledge solution: ID: 36.0.483196.2482974

How to set a VPN-1 Appliance back to factory defaults?

SecureKnowledge solution ID: 55.0.7154174.2684933

How to enable Network Voyager access to a VPN-1 Appliance


Cannot connect to VPN-1 Appliance box with web browser touse Voyager


Apache Server has security issues when running on the VPN-1

ApplianceSecureKnowledge solution: ID: 47.0.2078348.2535155

How to determine which fw processes are running on a VPN-1appliance box?


How to add a static ARP entry on boot-up on the VPN-1Appliance or Nokia products


How to improve the process time of fw logexport

http://support.checkpoint.com/support/publisher.asp?id=36.0.483196.2482974http://support.checkpoint.com/support/publisher.asp?id=36.0.483196.2482974http://support.checkpoint.com/support/publisher.asp?id=55.0.7154174.2684933http://support.checkpoint.com/support/publisher.asp?id=55.0.2396117.2581302http://support.checkpoint.com/support/publisher.asp?id=47.0.645111.2520774http://support.checkpoint.com/support/publisher.asp?id=47.0.645111.2520774http://support.checkpoint.com/support/publisher.asp?id=47.0.2078348.2535155http://support.checkpoint.com/support/publisher.asp?id=47.0.2078348.2535155http://support.checkpoint.com/support/publisher.asp?id=10022.0.1870093.2482034http://support.checkpoint.com/support/publisher.asp?id=10022.0.1870093.2482034http://support.checkpoint.com/support/publisher.asp?id=3.0.142568.2194045http://support.checkpoint.com/support/publisher.asp?id=3.0.142568.2194045http://support.checkpoint.com/support/publisher.asp?id=36.0.1227580.24963http://support.checkpoint.com/support/publisher.asp?id=36.0.1227580.24963http://support.checkpoint.com/support/publisher.asp?id=3.0.142568.2194045http://support.checkpoint.com/support/publisher.asp?id=3.0.142568.2194045http://support.checkpoint.com/support/publisher.asp?id=10022.0.1870093.2482034http://support.checkpoint.com/support/publisher.asp?id=10022.0.1870093.2482034http://support.checkpoint.com/support/publisher.asp?id=47.0.2078348.2535155http://support.checkpoint.com/support/publisher.asp?id=47.0.2078348.2535155http://support.checkpoint.com/support/publisher.asp?id=47.0.645111.2520774http://support.checkpoint.com/support/publisher.asp?id=47.0.645111.2520774http://support.checkpoint.com/support/publisher.asp?id=55.0.2396117.2581302http://support.checkpoint.com/support/publisher.asp?id=55.0.7154174.2684933http://support.checkpoint.com/support/publisher.asp?id=36.0.483196.2482974http://support.checkpoint.com/support/publisher.asp?id=36.0.483196.2482974


23/45



With Apache on VPN-1/FireWall-1, port 80 is available by defaultto any source IP address


How to move Network Voyager off default TCP port 80SecureKnowledge solution: ID: 47.0.2273301.2536889

Existing security policy will not allow GUI client connection


How to make changes to files on the VPN-1 Appliance when thepartition is mounted as Read-Only


How to reset the boot password on a VPN-1 Appliance


How to generate a core dump on a VPN-1 appliance and what isthe location of the core files


How to secure the Network Voyager (HTTP) access with SSH?


How to create a cron job on VPN-1 Appliance to automate `fwlogswitch`


Where is the IPSO system message file located?


How to set the domain name on VPN-1 Appliance?SecureKnowledge solution: ID: 36.0.608388.2485073
http://support.checkpoint.com/support/publisher.asp?id=47.0.2078348.2535155http://support.checkpoint.com/support/publisher.asp?id=47.0.2078348.2535155http://support.checkpoint.com/support/publisher.asp?id=47.0.2273301.2536889http://support.checkpoint.com/support/publisher.asp?id=36.0.2035410.2505437http://support.checkpoint.com/support/publisher.asp?id=21.0.1604679.2450378http://support.checkpoint.com/support/publisher.asp?id=21.0.1604679.2450378http://support.checkpoint.com/support/publisher.asp?id=55.0.3770696.2595751http://support.checkpoint.com/support/publisher.asp?id=10043.0.6749020.2629853http://support.checkpoint.com/support/publisher.asp?id=10043.0.6749020.2629853http://support.checkpoint.com/support/publisher.asp?id=10043.0.4251135.2570962http://support.checkpoint.com/support/publisher.asp?id=3.0.142526.2194045http://support.checkpoint.com/support/publisher.asp?id=3.0.142526.2194045http://support.checkpoint.com/support/publisher.asp?id=3.0.142518.2194045http://support.checkpoint.com/support/publisher.asp?id=36.0.608388.2485073http://support.checkpoint.com/support/publisher.asp?id=36.0.608388.2485073http://support.checkpoint.com/support/publisher.asp?id=3.0.142518.2194045http://support.checkpoint.com/support/publisher.asp?id=3.0.142526.2194045http://support.checkpoint.com/support/publisher.asp?id=3.0.142526.2194045http://support.checkpoint.com/support/publisher.asp?id=10043.0.4251135.2570962http://support.checkpoint.com/support/publisher.asp?id=10043.0.6749020.2629853http://support.checkpoint.com/support/publisher.asp?id=10043.0.6749020.2629853http://support.checkpoint.com/support/publisher.asp?id=55.0.3770696.2595751http://support.checkpoint.com/support/publisher.asp?id=21.0.1604679.2450378http://support.checkpoint.com/support/publisher.asp?id=21.0.1604679.2450378http://support.checkpoint.com/support/publisher.asp?id=36.0.2035410.2505437http://support.checkpoint.com/support/publisher.asp?id=47.0.2273301.2536889http://support.checkpoint.com/support/publisher.asp?id=47.0.2078348.2535155http://support.checkpoint.com/support/publisher.asp?id=47.0.2078348.2535155


24/45

High Availability VRRP Monitored Circuit on IPSO 3.1 and later VRRP v2


High Availability VRRP Monitored Circuit on IPSO 3.1and later

IPSO 3.1 introduces a new VRRP configuration called VRRP Monitored Circuit. This method of setting up

VRRP between two or more FireWalls eliminates the creation of asynchronous routes that occurs when a singleinterface fails.

This section explains how VRRP v2 and Monitored Circuits differ, gives an example VRRP v2 and Monitored

Circuit configuration, and provides a migration plan from VRRP v2 to Monitored Circuits.

Monitored Circuit makes a VPN-1/FireWall-1 let go of its priority over IP addresses associated with its active

network -interfaces when a single network interface loses its link state. This results in the secondary

VPN-1/FireWall-1 taking on all of these IP addresses.

Hosts configured with a default route will now have the entire network connection passing through the

secondary FireWall, rather than passing through the primary in one direction and coming back through the

secondary.

Asymmetric routing needs to be eliminated because of the limitations of the VPN-1/FireWall-1 synchronization

feature, which prevent the secondary FireWall from accepting all types of network connections that wereallowed by the primary FireWall.

A summary of differences between VRRP v2 and MonitoredCircuits

VRRP v2

Backup of router interface address (Real IP address)

When in master mode responds to ICMP echo

Requires use of routing protocol to recover from single interface failure Cannot track other interface's (Whether up or down)

VRRP "Monitored circuit"

Uses a virtual IP address (Not real address)

Does not respond to ICMP echo request

Does not require the use of additional routing protocols

Can track multiple interfaces (whether up or down)


25/45

High Availability VRRP Monitored Circuit on IPSO 3.1 and later VRRP v2 Configuration


VRRP Configuration

VRRP v2 Configuration

A standard four interface VRRP v2 configuration might look something like this:

FireWallA:

eth-s1p1c0 (External) 205.226.10.1/24

eth-s1p2c0 (Internal) 192.168.2.1/24

eth-s1p3c0 (DMZ) 192.168.3.1/24

eth-s1p4c0 (Sync) 192.168.4.1/24

FireWallB:

eth-s1p1c0 (External) 205.226.10.2/24

eth-s1p2c0 (Internal) 192.168.2.2/24

eth-s1p3c0 (DMZ) 192.168.3.2/24

eth-s1p4c0 (Sync) 192.168.4.2/24

FireWallB uses VRRP v2 to fail-over the external, internal and DMZ interfaces of FireWallA. Hosts using staticrouting will use the .1 address (i.e. the IP addresses of A). In the event that an interface on FireWallA fails,

FireWallB takes over the IP address of the failed interface.

OSPF is used to ensure packets are routed around the failure of a specific interface.

In a Monitored Circuit configuration, you must dedicate an IP address on each interface you wish to fail-over.

This means you need at least three IP addresses on each network the FireWalls are attached to, one for each

VPN-1 Appliance, plus an extra IP.

This extra IP address, referred to as the "backup IP" in the configuration screen, is what your routers and hosts

will point to. In a properly configured Monitored Circuit, the failure of a single interface on FireWallA will

cause the entire backup IPs to fail over to FireWallB.

Because FireWallB will be serving the backup IPs, all traffic will be routed through FireWallB without needing

to go through FireWallA at all. OSPF is not needed to maintain coherency because asymmetric routing shouldnot occur as it can with VRRP v2.

How to Set up Monitored Circuits

Using Network Voyager, get into the VRRP configuration on the primary. Using the above example, we would

want to configure the External, Internal, and DMZ interface for VRRP. On each of the interfaces, select

"Monitored Circuits" and click apply. For each interface, you will be asked to create a virtual router. For each

interface, specify a number between 1 and 255. This number must be unique on each subnet. It is recommended

you pick a different number for each interface.

Once you have specified a virtual router ID for each interface, click on applies. You will then be presented with

a variety of options for each virtual router ID. The options are:

Priority: A number from 1 (lowest) to 254 (highest). This number should be highest on the primary system. Ona secondary box, this number should be lower than on the primary, but greater than the primary's priority minus

the appropriate priority delta.

Hello Interval: This is how frequently (in seconds) the system will send out VRRP Hello messages. This

should be the same on both boxes. The default (if not specified) is 1 second.

Backup Address: This is the address that is being "failed over" between the two boxes. This IP must not

otherwise be associated with an interface on either box. This will be the IP address your client machines/routers

will use for routing.


26/45

High Availabil ity VRRP Monitored Circuit on IPSO 3.1 and later A Sample Monitored Circuit Configuration


Monitor Interface and Priority Delta: If the selected interface fails on this system, the "priority" the system

will have for this virtual router ID will be reduced by the specified priority delta (see below). This will allow the

secondary system to take over.

Authentication: You can require a plaintext password for any VRRP packets received about this virtual router

ID.

A Sample Monitored Circuit Configuration

FireWallA:

eth-s1p1c0 (External) 205.226.10.1/24

Virtual Router: 10

Priority: 100

Hello Interval: 1

Backup IP: 205.226.10.3

Monitor Interfaces:

eth-s1p2c0 Priority Delta: 10


eth-s1p2c0 (Internal) 192.168.2.1/24

Virtual Router: 2Priority: 100

Hello Interval: 1

Backup IP: 192.168.2.3

Monitor Interfaces:



eth-s1p3c0 (DMZ) 192.168.3.1/24

Virtual Router: 3

Priority: 100

Hello Interval: 1

Backup IP: 192.168.3.3

Monitor Interfaces:



eth-s1p4c0 (Sync) 192.168.4.1/24

FireWallB:

eth-s1p1c0 (External) 205.226.10.2/24

Virtual Router: 10

Priority: 95

Hello Interval: 1

Backup IP: 205.226.10.3

Monitor Interfaces:

eth-s1p2c0 Priority Delta: 10eth-s1p3c0 Priority Delta: 10

eth-s1p2c0 (Internal) 192.168.2.2/24

Virtual Router: 2

Priority: 95

Hello Interval: 1

Backup IP: 192.168.2.3

Monitor Interfaces:




27/45

High Availability VRRP Monitored Circuit on IPSO 3.1 and later Some VRRP configuration notes


eth-s1p3c0 (DMZ) 192.168.3.2/24

Virtual Router: 3

Priority: 95

Hello Interval: 1

Backup IP: 192.168.3.3

Monitor Interfaces:



eth-s1p4c0 (Sync) 192.168.4.2/24

Some VRRP configuration notes

1. The Hello Interval, priority deltas, and authentication should be the same on all virtual routers.

2. The priority delta on the secondary (95) should be numerically lower than the primary's priority (100).

3. The backup IPs are what will be used in the routing configuration for clients and other routers.

4. Double-check to make sure the Firewall is allowing VRRP packets out of its interfaces:

Create a workstation object with the name VRRP-MCAST-NET for address 224.0.0.18

Then Create a rule that says Source: FireWall, Dest: VRRP-MCAST-NET, Action: Accept

How to tell that the VRRP configuration is correct

Each machine will send out VRRP Hello messages every second. Since FireWallA will broadcast the highest

priority for each virtual router, all the "backup" IP addresses will be served by FireWallA.

What Happens if FireWallA Fails

Say FireWallA suffers a catastrophic failure (hard drive crash, kernel panic, etc). FireWallB will stop hearing

VRRP Hello requests from A and take over. All backup IP addresses will now be associated with FireWallA.

Once FireWallA returns to an operational state, all backup IPs will return to FireWallA.

Say instead of FireWallA suffering a catastrophic failure, a single interface on FireWallA goes bad (eth-

s1p1c0). FireWallB will sense the failure of that interface because it will stop receiving VRRP Hello requestsfrom FireWallA. FireWallB will take over this interface. FireWallA will know that its eth-s1p1c0 interface is

currently offline. Because the other virtual routers on FireWallA are configured to monitor this interface, their

effective priority will be reduced by 10 each. FireWallA will have virtual routers 2 and 3 each with a priority of

90. FireWallB is still broadcasting that it has priority 95 for these virtual routers. Because FireWallB will have a

higher priority, it will take over the Backup IPs served by virtual routers 2 and 3. All of this will happen within

the space of approximately 3-5 seconds.

What Happens when FireWallA Recovers

Once the eth-s1p1c0 interface of FireWallA is operating again (perhaps it was because of a loose cable),

FireWallB will start seeing VRRP Hello requests. The other virtual routers on FireWallA will notice that eth-

s1p1c0 and re-adjust the priorities accordingly. FireWallA will then have the highest priority for all virtual

routers and all backup IPs will fail back to FireWallA.

Migrating from VRRP v2 to Monitored Circuits

It is fairly straightforward to migrate your existing VRRP v2 configuration over to monitored circuits. You will

need to make sure you can allocate an additional IP address on each network to which your FireWall is

attached.

Should you decide to use the new IPs for the backup IPs, then you will need to reconfigure the routing on all the

hosts and routers attached to the FireWall to ensure they are using the new "backup" IPs instead of the IPs


28/45

High Availability VRRP Monitored Circuit on IPSO 3.1 and later Migrating from VRRP v2 to Monitored Circuits


associated with FireWallA. Aside from that, you would simply disable VRRP on FireWallB, change the

configuration on FireWallA to use Monitored Circuits, and set up FireWallB with Monitored Circuits. You can

use the examples in this document as a guide for what the configuration should look like.

If your attached hosts and routers are using FireWallA's IPs for routing (e.g. they are the default route for hosts

behind it), then you can use your existing IPs on "A" as the "backup" IPs and pick new IPs for each interface

that will be failed over. Note that this will also require many additional configuration changes on

VPN-1/FireWall-1, including new licenses.

Here is the step-by-step process, using the original VRRP v2 configuration above as an example. Performing

this procedure in a production environment will cause an outage. It is recommended you do this during a

maintenance window and that you have console access while doing so. If you are using encryption, the remote

sites will have to re-fetch your encryption keys. SecuRemote users will have to "update" the site.

1. Disable VRRP on FireWallB, then FireWallA.

2. On FireWallA, configure the failover interfaces with new IP addresses. We will assign these interfaces

205.226.10.3, 192.168.2.3, and 192.168.3.3 accordingly.

3. In Network Voyager, reconfigure the host address assignments on FireWallA (and FireWallB, if necessary)

to reflect the new IP assignments for FireWallA.

4. If this hasn't already been done, install new licenses on FireWallA. Do a fwstop and fwstart for the

new licenses to take effect.

5. In VPN-1/FireWall-1, re-configure the network object of FireWallA. Before starting to make changes, it

should be 205.226.10.1. We will change it to 205.226.10.3. Change the interfaces listed in the interface tab

MANUALLY as there's a known bug when using an SNMP Get after changing the object's IP.

6. If you have encryption defined, regenerate the necessary encryption keys, as this will be required.

7. Re-install the security policy.

8. Configure Monitored Circuits on FireWallA. The configuration should look like this:

eth-s1p1c0 (External) 205.226.10.3/24

Virtual Router: 10

Priority: 100

Hello Interval: 1

Backup IP: 205.226.10.1

Monitor Interfaces:



eth-s1p2c0 (Internal) 192.168.2.3/24

Virtual Router: 2

Priority: 100

Hello Interval: 1

Backup IP: 192.168.2.1

Monitor Interfaces:

eth-s1p1c0 Priority Delta: 10eth-s1p3c0 Priority Delta: 10


29/45

High Availability VRRP Monitored Circuit on IPSO 3.1 and later Problem


eth-s1p3c0 (DMZ) 192.168.3.3/24

Virtual Router: 3

Priority: 100

Hello Interval: 1

Backup IP: 192.168.3.1

Monitor Interfaces:



eth-s1p4c0 (Sync) 192.168.4.1/24

8. Configured Monitored Circuits on FireWallB. The configuration should

look like this:

eth-s1p1c0 (External) 205.226.10.2/24

Virtual Router: 10

Priority: 95

Hello Interval: 1

Backup IP: 205.226.10.1

Monitor Interfaces:eth-s1p2c0 Priority Delta: 10


eth-s1p2c0 (Internal) 192.168.2.2/24

Virtual Router: 2

Priority: 95

Hello Interval: 1

Backup IP: 192.168.2.1

Monitor Interfaces:



eth-s1p3c0 (DMZ) 192.168.3.2/24

Virtual Router: 3

Priority: 95

Hello Interval: 1

Backup IP: 192.168.3.1

Monitor Interfaces:



eth-s1p4c0 (Sync) 192.168.4.2/24

Solving Common VRRP Problems

Problem

The IP address(es) used as the default gateway by other systems currently belongs to the primary FireWall

under VRRP Version 2. The primary FireWall will need to be assigned new IP addresses

Solution

1. First, setup the secondary FireWall to use VRRP Monitored Circuit to backup the real IP addresses of the

primary FireWall. The VRRP configuration on the secondary will backup the VRID of the primary while it


30/45

High Availability VRRP Monitored Circuit on IPSO 3.1 and later VRRP related SecureKnowledge solutions


is supporting VRRP Version 2. In this state, the primary retains ownership and traffic continues to flow

through the primary.

2. On the primary, disable VRRP on all interfaces at the same time. Traffic will now flow through the

secondary.

3. Change the IP addresses on the primary.

4. Change the IP addresses in the VPN-1/FireWall-1 object representing the primary. You will have toregenerate your encryption keys.

5. Enable VRRP Monitored Circuit on the primary so it is backing up the VRID number that it was previously

the owner of while running VRRP Version 2. If you want the primary to take back the network flow, then

make its priority a numerical value greater than the priority used by the secondary on all VRRP enabled

network interfaces.

VRRP related SecureKnowledge solutions

How to setup HA VPN for a VPN-1 Appliance

SecureKnowledge Solution ID: 36.0.2468192.2513640

What is VRRP Monitored Circuit?


How long does it take for VRRP Monitored Circuits to converge?


When testing VRRP MC by pulling an interface, the other interfaces do not let go of their IP addresses


Which VRRP should one use?


What is the RFC number for VRRP, and where is the RFC located?


How should I configure my Ethernet switch to work with VRRP?


Tools to monitor and troubleshoot VRRP in IPSO 3.X systems


Can VRRP be used to back up a physical interface connected to a LAN with another physical interface

connected to the same LAN?


Can eth-s1p2 be used to backup eth-s1p1 on the same LAN?


Why does VRRP not work when ipsrd crashes and comes back up in a certain configuration?


IPSO 3.0x operating system does not send out VRRP HELLO packets.


Excessive VRRP Flapping (provides fix to ifm binary)
http://support.checkpoint.com/support/publisher.asp?id=36.0.2468192.2513640http://support.checkpoint.com/support/publisher.asp?id=47.0.2688826.2541187http://support.checkpoint.com/support/publisher.asp?id=55.0.6517817.2665001http://support.checkpoint.com/support/publisher.asp?id=55.0.5928491.2651689http://support.checkpoint.com/support/publisher.asp?id=55.0.5928483.2651689http://support.checkpoint.com/support/publisher.asp?id=55.0.5928464.2651689http://support.checkpoint.com/support/publisher.asp?id=55.0.5193914.2631768http://support.checkpoint.com/support/publisher.asp?id=55.0.5194917.2632012http://support.checkpoint.com/support/publisher.asp?id=55.0.5928499.2651689http://support.checkpoint.com/support/publisher.asp?id=55.0.5928499.2651689http://support.checkpoint.com/support/publisher.asp?id=55.0.5928499.2651689http://support.checkpoint.com/support/publisher.asp?id=55.0.5467833.2637542http://support.checkpoint.com/support/publisher.asp?id=47.0.169000.2516436http://support.checkpoint.com/support/publisher.asp?id=36.0.174313.2473478http://support.checkpoint.com/support/publisher.asp?id=36.0.174313.2473478http://support.checkpoint.com/support/publisher.asp?id=47.0.169000.2516436http://support.checkpoint.com/support/publisher.asp?id=55.0.5467833.2637542http://support.checkpoint.com/support/publisher.asp?id=55.0.5928499.2651689http://support.checkpoint.com/support/publisher.asp?id=55.0.5928499.2651689http://support.checkpoint.com/support/publisher.asp?id=55.0.5928499.2651689http://support.checkpoint.com/support/publisher.asp?id=55.0.5194917.2632012http://support.checkpoint.com/support/publisher.asp?id=55.0.5193914.2631768http://support.checkpoint.com/support/publisher.asp?id=55.0.5928464.2651689http://support.checkpoint.com/support/publisher.asp?id=55.0.5928483.2651689http://support.checkpoint.com/support/publisher.asp?id=55.0.5928491.2651689http://support.checkpoint.com/support/publisher.asp?id=55.0.6517817.2665001http://support.checkpoint.com/support/publisher.asp?id=47.0.2688826.2541187http://support.checkpoint.com/support/publisher.asp?id=36.0.2468192.2513640


31/45

High Availability VRRP Monitored Circuit on IPSO 3.1 and later VRRP related SecureKnowledge solutions



Why am I not able to ping the VRRP virtual IP address from the VRRP master router?

http://support.checkpoint.com/support/publisher.asp?id=36.0.174313.2473478http://support.checkpoint.com/support/publisher.asp?id=36.0.174313.2473478http://support.checkpoint.com/support/publisher.asp?id=36.0.174313.2473478http://support.checkpoint.com/support/publisher.asp?id=36.0.174313.2473478http://support.checkpoint.com/support/publisher.asp?id=36.0.174313.2473478http://support.checkpoint.com/support/publisher.asp?id=36.0.174313.2473478http://support.checkpoint.com/support/publisher.asp?id=36.0.174313.2473478http://support.checkpoint.com/support/publisher.asp?id=55.0.5467843.2637542http://support.checkpoint.com/support/publisher.asp?id=55.0.5467843.2637542


32/45

VPN-1 Appliance Command Line Interface newimage


VPN-1 Appliance Command Line Interface

I. Controlling IP forwarding on a VPN-1 Appliance

How to control IP forwarding of a FireWall on the VPN-1 Appliance platform SecureKnowledge solution ID:21.0.1549216.2444425

There is a general agreement that it is best to boot a FireWall so that network connections are not allowed to

pass through until the FireWall is fully up and functional. Two methods are used with VPN-1/FireWall-1 on

various platforms to guarantee that the FireWall itself is not vulnerable during the boot process:

Disable IP forwarding

Load a default filter that blocks all inbound network connections.

IPSO 3.x offers both facilities. If VPN-1/FireWall-1 is not installed on a VPN-1 appliance; IP Forwarding is

enabled by default. If VPN-1/FireWall-1 is installed, it is disabled by default. Furthermore, if

VPN-1/FireWall-1 is unable to load a policy from a management console and there is no previously loaded

policy stored on the platform, the system will load a default filter that blocks all inbound network connections.

If VPN-1/FireWall-1 starts up and loads a policy successfully, IP Forwarding will be enabled. When

VPN-1/FireWall-1 is stopped (by using the fwstop command), IP Forwarding will again be disabled.

To manually enable IP Forwarding, use the command:

ipsofwd on admin

To manually disable IP Forwarding, use the command:

ipsofwd off admin

(Note in IPSO 3.0.x, the command is fwfwd rather than ofipsofwd)

The admin part of both commands is simply a tag to let you know who last changed IP Forwarding. You can

determine who last changed the state of IP Forwarding by using the command ipsofwd list

II. Installing new images/packages using the newimage andnewpkg commands

newimage and newpkg are used to installing new images/packages.

newimage

Syntax

newimage [[-i | -l localfile] [-R]] [-r imagename]

Optionsparameter meaning

-i: Load a new image interactively

-l Localf ile: extract the new image from an extant f ile

-r Imagename: specify imagename to run at next boot

-R: Use newly-installed image to run at next boot
http://support.checkpoint.com/support/publisher.asp?id=21.0.1549216.2444425http://support.checkpoint.com/support/publisher.asp?id=21.0.1549216.2444425


33/45

VPN-1 Appliance Command Line Interface newpkg


parameter meaning

-k Keep currently installed packages active.

Without this flag, the previously installed packages will have to be reactivated (or turned "on")when a new IPSO image is installed.

The only time one would not want to use the k option is when upgrading to a newer version

of IPSO, for which some packages had to be recompiled. This is especially significant in thetransition between 3.2.x and 3.3.

In this case, while still running 3.2.x, first upgrade VPN-1/FireWall-1 to the 3.3 package(though you should not yet enable it to run at reboot). Then, upgrade to IPSO 3.3. Afterbooting from 3.3, enable the 3.3 VPN-1/FireWall-1 package using Network Voyager.

-v verbose ftp

newpkg

Syntax

newpkg [options]

Options

parameter meaning

-s

server_ipaddr

The server IP address (if media is FTP/AFTP)

-l user User name (if media is FTP)

-p password User password (if media is FTP)

-m media_type Media type (CDROM/AFTP/FTP/LOCAL)

-d Debug

-v Verbose

-n newpkg Full pathname of new package (eg: /pub/current/xxx.tgz)

-o oldpkg Full pathname of old package for upgrade (eg: /opt/xxx)

-i Install only (do not activate)

-h Help

III. Using the tcpdump utility to view packets on an interface

See the related SecureKnowledge solution: How to use the 'tcpdump' utility to troubleshoot network problems

(ID 10043.0.7774592.2711980 )

The tcpdump command is used to troubleshoot network problems by viewing packets on a interface

This discussion of the tcpdump command is intended as a supplement to the Network Voyager man pages.Several examples are given:

Tcpdump, provided with the IPSO software, is very much like the tcpdump or snoop programs on a UNIX

workstation. Tcpdump is used to see the traffic on a network, not to alter it. The information below contains

some important features and commands that are used with tcpdump. For further information, see the man page

for tcpdump, placed under Network Voyager.
http://support.checkpoint.com/support/publisher.asp?id=10043.0.7774592.2711980http://support.checkpoint.com/support/publisher.asp?id=10043.0.7774592.2711980


34/45

VPN-1 Appliance Command Line Interface General Notes


General Notes

The interface must be up before running tcpdump.

tcpdump defaults to lowest number port configured up in the system interface list.

control-c will stop tcpdump.

All ports can be monitored with the exception of the ATM port on an FAS type ATM card.

parameter meaning

-i tcpdump per specific interface.

-e Displays source and destination MAC addresses

tcpdump accesses an interface directly, so it will see packets before VPN-1/FireWall-1. In other words,

tcpdump will see incoming packets on an interface before VPN-1/FireWall-1 enforces the security policy on

those packets.

Examples

tcpdump -i eth-s2p3c0 proto ospf

Shows only ospf on that interface

tcpdump -i eth-s2p1c0 proto igrp

Shows only the igrp traffic on that wire.

How to show all Telnet traffic

tcpdump -i port

Example

tcpdump -i eth-s1p1c0 port telnettcpudmp -i eth-s1p1c0 port 23

How to show all bootp/dhcp traffic.

tcpdump -i can specify an IP or UDP port

Example

tcpdump -i eth-s2p1c0 udp port 68

will show all bootp/dhcp traffic.

How to filter traffic

Example

tcpdump -i eth-s1p1c0 not port 80

will not show WWW traffic on that interface


35/45

VPN-1 Appliance Command Line Interface How to specify how much of the packet to view


How to specify how much of the packet to view

Example

tcpdump -i eth-s1p1c0 -s 320 -vv

Will receive 320 bytes of the packet, with verbose output.

How to save a trace to a file (the w flag)

Using the tcpdump program with the -w flag generates a trace file. This copies the packet to a file on the hard-

drive of the unit. This can then be used to mail back to Support, or moved to another computer where tcpdump

can be used to view that file.

The tcpdump copies the first 68 bytes of every packet, unless the capture size is increased. For users running

without data encryption, passwords are also copied into this file.

If the network being snooped is busy this file will grow quite fast. It is usually a good idea to create this file on

the /usr partition as this is the 810Mb area. Remember to delete this file as it takes up quite a lot of space.

Exampletcpdump -i eth-s1p1c0 -w /usr/trace.file

Will not display packets, doing a control-c will end the capture and print how many Packets were captured

RIP example

tcpdump -i eth-s1p1c0 -s 320 -vv port 520

Shows all RIP traffic on the network attached to eth-s1p1c0

Port 520 is also the port used by 'routed' on UNIX workstations.

OSPF exampletcpdump -i atm-s3p1c0 -s 320 -vv proto ospf

Shows all OSPF traffic on the ATM link, including Link State Advertisements (LSAs) and full information on

routes.

IGRP example

tcpdump -i eth-s1p1c0 -s 320 -vv proto igrp

Shows all IGRP traffic on the network connected to eth-s1p1c0.

GSMP exampletcpdump -m -i atm-s1p1c0

The -m parameter specifies the use of multiple output lines when decoding protocol packets. For the protocols

decode that support this option, this is the most verbose level. Currently this is only supported by GSMP.

NOTE: You must first configure the GSMP link before tcpdump will work (using the command ifconfig

atm-s1p1c0 up)


36/45

VPN-1 Appliance Command Line Interface How to filter on a specific ATM VCI


How to filter on a specific ATM VCI

Syntax

atm vci 0/xx

where xx is the vci

atm invci 0/xxatm outvci 0/xx

You can combine these with the OR operator, but AND doesn't make much sense since there is only a single vci

per packet.

Example

tcpdump -i atm-s1p1 atm invci 0/32 or atm vci 0/390000000

Filtering for a specific host

tcpdump -i interface host X.X.X.X

Dumping the data portion of the packet in ASCII

It may be desirable to see the data portion of the packet for further troubleshooting. For example, this will show

the first 128 bytes of the packet in ASCII and Hex:

# tcpdump -i eth-s1p1c0 -s 128 -X host 172.31.0.43 and tcp port 80

tcpdump: listening on eth-s1p1c0

13:17:50.608103 205.226.3.134.2385 > 172.31.0.43.80: (DF) [tos 0x10]

13:17:50.609351 172.31.0.43.80 > 205.226.3.134.2385:

13:17:50.689136 205.226.3.134.2385 > 172.31.0.43.80: (DF) [tos 0x10]

13:17:56.198998 205.226.3.134.2385 > 172.31.0.43.80:

47 45 54 20 2f 20 48 54 54 50 2f 31 2e 30 0d 0a

G E T / H T T P / 1 . 0 . . . . ( D F ) [ t o s 0 x 1 0 ]

13:17:56.199581 172.31.0.43.80 > 205.226.3.134.2385:

48 54 54 50 2f 31 2e 30 20 33 30 32 20 46 69 72

H T T P / 1 . 0 3 0 2 F i r

65 77 61 6c 6c 31 2d 52 65 64 69 72 65 63 74 69

e w a l l 1 - R e d i r e c t i

6f 6e 0d 0a 4c 6f 63 61 74 69 6f 6e 3a 20 68 74

o n .. .. L o c a t i o n : h t

74 70 3a 2f 2f 32 00 00 f4 f7 14 37 18 0c 03 00

t p : / / 2 . . . . . . . . . . 7 . . . . . . . .

4a 00 00 00 4a 00 00 00

J . . . . . . J . . . . . .

13:17:56.199704 172.31.0.43.80 > 205.226.3.134.2385:

13:17:56.287491 205.226.3.134.2385 > 172.31.0.43.80: (DF) [tos 0x10]

13:17:56.288551 205.226.3.134.2385 > 172.31.0.43.80: (DF) [tos 0x10]

13:17:56.288935 172.31.0.43.80 > 205.226.3.134.2385:


37/45

VPN-1 Appliance Command Line Interface iclid commands


IV. Providing routing diagnostics using the iclid command

Note: See the SecureKnowledge solution How to use the iclid command to get routing diagnostics on a VPN-

1 appliance? (ID: 10043.0.7610510.2703345 )

The iclid (IPSRD CLI Daemon) utility's man page can be found in the Network Voyager interface.

While looking at the home page, select Doc> Monitoring> Displaying Routing Daemon Status (iclid).

Routing diagnostic information can be obtained by creating a telnet session on the router and running iclid

(Ipsrd command-line interface daemon).

iclid commands

parameter meaning

help Displays help information.

show Shows categorized system information.

Top-level iclid categories:

bgp

bootpdvmrp

igmp

interfaces

memory

ospf

resource

rip

route

vrrp

Type ? at any point for help or possible command completions.

Also, commands may be abbreviated when there is no ambiguity.

get Shows detailed raw information.

quit Quit.

? Shows all possible command completions.

iclid command examples

command meaning

show ospf Shows OSPF summary information

show ospf neighbor (s o n) Shows OSPF neighbor information

show route Shows all routes

show route bgp

127

Shows only BGP routes that start wi

atrg nokia appliance

Documents