ATRG Nokia Appliance

Check Point VPN-1 Appliance Advanced Technical Reference Guide
Check Point 2000
Contents:
Preface ...........................................................................................................................................................3 Scope........................................................................................................................................................3 Links to SecureKnowledge .......................................................................................................................3 Who should use this Guide.......................................................................................................................3 How to obtain the latest version of this Guide ..........................................................................................3 Feedback Please! .....................................................................................................................................3 Introduction ...................................................................................................................................................4 IPSO The VPN-1 Appliance Operating System .......................................................................................5 IPSO design more secure .....................................................................................................................5 IPSO File System Layout..........................................................................................................................6 IPSO information gathering utility ipsoinfo ...........................................................................................6 Upgrading a VPN-1 Appliance .....................................................................................................................7 Before You Begin......................................................................................................................................7 Other Considerations................................................................................................................................7 Begin the Upgrade....................................................................................................................................7 Notes.......................................................................................................................................................14 Upgrading 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)..........17 Allowing routing protocols (RIP, OSPF, IGRP, and BGP) through VPN-1/FireWall-1 ...........................18 Monitoring memory and CPU utilization .................................................................................................19 Configuring the default filter on VPN-1 Appliance ..................................................................................21 Receiving the error message : "FW_IPADDR: cannot get my IPADDR" ...............................................21 How to set a VPN-1 Appliance back to factory defaults? .......................................................................21 How to enable Network Voyager access to a VPN-1 Appliance ............................................................21 Cannot connect to VPN-1 Appliance box with web browser to use Voyager.........................................21 Apache 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?...................................21 How to add a static ARP entry on boot-up on the VPN-1 Appliance or Nokia products ........................21 How to improve the process time of fw logexport...................................................................................21 With Apache on VPN-1/FireWall-1, port 80 is available by default to any source IP address ...............22 How to move Network Voyager off default TCP port 80.........................................................................22 Existing security policy will not allow GUI client connection...................................................................22 How to make changes to files on the VPN-1 Appliance when the partition is mounted as Read-Only..22 How to reset the boot password on a VPN-1 Appliance ........................................................................22 How to generate a core dump on a VPN-1 appliance and what is the location of the core files............22 How to secure the Network Voyager (HTTP) access with SSH? ...........................................................22 How to create a cron job on VPN-1 Appliance to automate `fw logswitch` ............................................22 Where is the IPSO system message file located? .................................................................................22 How 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 ...................................................23 VRRP Configuration ...............................................................................................................................24 Solving Common VRRP Problems .........................................................................................................28 VPN-1 Appliance Command Line Interface ..............................................................................................31 I. Controlling IP forwarding on a VPN-1 Appliance.................................................................................31 II. Installing new images/packages using the newimage and newpkg commands .............................31 III. Using the tcpdump utility to view packets on an interface.................................................................32
IV. Providing routing diagnostics using the iclid command...................................................................36 V. ping, netstat and traceroute...........................................................................................................37 VI. route.................................................................................................................................................37 VI. Using the ipsrd command to troubleshoot network routing problem ...............................................37 VII. Using the ipsctl command line to set kernel variables....................................................................38 Further information.....................................................................................................................................40 Check Point Support Information............................................................................................................40 Nokia support Information ......................................................................................................................44
VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000
Preface
IPSO 3.0.x
Preface
Scope
The VPN-1 Appliance Advanced Technical Reference Guide is intended to help the System Administrators resolve 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.html and other places in the Check Point Premium Support site http://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 ehareven@checkpoint.com
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 most versions 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.
IPSO The VPN-1 Appliance Operating System
IPSO 3.0.x

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.
IPSO 3.0.x
IPSO File System Layout

Directory /opt /var /config Contains Software packages, such as Check Point VPN-1/FireWall-1, Websense, OpenService, etc. IPSO admin home directory 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 IPSO configuration set contains all of the configuration information for a VPN-1 Appliance. Small enough to fit onto a floppy diskette, it can completely restore the configuration on a newly installed platform. /image Kernel image. The IPSO image is an entire kernel release. When a new image is loaded with the newimage 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 the new 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.
Upgrading a VPN-1 Appliance
IPSO 3.0.x

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. 2. 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. 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. 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. 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. 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.
3.
4.
5.
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
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, download the 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 directory and 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. 8. Reboot, but do not activate any packages, as you will need to upgrade FireWall-1 first. Upgrade FireWall-1 3.0b p3078plus for IPSO 3.0.x to VPN-1/FireWall-1 4.0 SP1. See
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. 2. Install IPSO 3.1.3 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.4

Either 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
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
10
IPSO 3.1.5, 3.2
Upgrading VPN-1/FireWall-1 Packages on page 16). Depending on your existing configuration, this may not be necessary. 3. 4. Upgrade Boot Manager on IP330 and IP650 to IPSO 3.2 Boot Manage (see Boot Manager Upgrade on page 14). Rename Existing Active File to machine-name_31x See Managing IPSO Configuration Sets on page 15 for more details. 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 of newimage 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.2

These 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
11
IPSO 3.1.5, 3.2
Upgrading VPN-1/FireWall-1 Packages on page 16) Depending on your existing configuration, this may not be necessary. 2. Upgrade VPN-1/FireWall-1 to 4.0 SP5 (see
12
IPSO 3.1.5, 3.2
Upgrading VPN-1/FireWall-1 Packages on page 16) Depending on your existing configuration, this may not be necessary. 3. Upgrade VPN-1/FireWall-1 to 4.1 (see
13
Boot Manager Upgrade
Upgrading VPN-1/FireWall-1 Packages on page 16) 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 8 Gbyte. 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 See Managing IPSO Configuration Sets on page 15 for more details. 6. Install IPSO 3.2.1 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. 2. Boot single-user 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. 4. Move /image/current to point to IPSO 3.1.5 Reboot machine
14
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.x 3.2.0 3.2.1 3.1.x 3.0.x 3.1.5 3.1.x 3.0.x is not supported. You are better off reinstalling 3.0.x and restoring the configuration files from backup. is supported if you supply a valid 3.1.x configuration file. is not supported. You are better off reinstalling 3.0.x and restoring the configuration files from backup. is not supported. You are better off reinstalling 3.0.x and restoring the configuration files from backup.
Backup Configuration Information

Problem
The 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
15
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 newpkg commands 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 3.0.x 3.1.x 3.2.x 3.3

1 2
Compatible VPN-1/FireWall-1 Version(s) 3.0b 3078plus and earlier 3.0b 3078plus , 4.0 Service Packs 1, 2, and 4 All 4.0 Service Packs, 4.1 Base , and 4.1 Service Pack 1 All 4.1 Service Packs
2 2 2 1 1
There are different builds for IPSO 3.0.x and IPSO 3.1.x There 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 3.0b 3078plus 4.0 Service Pack 1 4.0 Service Pack 5 4.1 Base or 4.1 Service Pack 1 upgrades the following VPN-1/FireWall-1 versions All previous 3.0b versions 3.0b 3078plus Any previous 4.0 Service Pack 4.0 Service Pack 3 and later
16
VPN-1 Appliance Common issues
Scenario #1 (Without NAT)

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.
17
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) through VPN-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 UDP port 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 Neighbor 2 -- Network 2 Broadcast -- RIP -- Accept Neighbor 3 -- Network 3 Broadcast -- RIP -- Accept
B. RIP version 2
RIPv2 can use either the RIPv1 broadcast transport mechanism or a multicast transport (RIP2ROUTERS.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. 2. Create a workstation object of 224.0.0.5 and call it OSPF-ALL.MCAST.NET Create another workstation object of 224.0.0.6 and call it OSPF-DSIG.MCAST.NET
18
III. IGRP
3.
Then create the following rule:

Source Any Destination OSPF Objects Service FireWall OSPF Action Accept Track 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.
19
#!/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 >> $OUTFILE echo "# 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
20
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 my IPADDR"

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 to use Voyager
Apache Server has security issues when running on the VPN-1 Appliance
How to determine which fw processes are running on a VPN-1 appliance box?

How to add a static ARP entry on boot-up on the VPN-1 Appliance or Nokia products
How to improve the process time of fw logexport

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

How to move Network Voyager off default TCP port 80

Existing security policy will not allow GUI client connection

How to make changes to files on the VPN-1 Appliance when the partition 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 is the 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 `fw logswitch`

Where is the IPSO system message file located?

How to set the domain name on VPN-1 Appliance?

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

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 single interface 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 were allowed by the primary FireWall.
A summary of differences between VRRP v2 and Monitored Circuits

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)
23
VRRP v2 Configuration
VRRP Configuration
VRRP v2 Configuration
A standard four interface VRRP v2 configuration might look something like this: FireWallA: eth-s1p1c0 eth-s1p2c0 eth-s1p3c0 eth-s1p4c0 FireWallB: eth-s1p1c0 eth-s1p2c0 eth-s1p3c0 eth-s1p4c0 (External) (Internal) (DMZ) (Sync) 205.226.10.1/24 192.168.2.1/24 192.168.3.1/24 192.168.4.1/24
(External) (Internal) (DMZ) (Sync)
205.226.10.2/24 192.168.2.2/24 192.168.3.2/24 192.168.4.2/24
FireWallB uses VRRP v2 to fail-over the external, internal and DMZ interfaces of FireWallA. Hosts using static routing 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 should not 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. On a 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.
24
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: eth-s1p3c0 Priority Delta: eth-s1p2c0 (Internal) 192.168.2.1/24 Virtual Router: 2 Priority: 100 Hello Interval: 1 Backup IP: 192.168.2.3 Monitor Interfaces: eth-s1p1c0 Priority Delta: eth-s1p3c0 Priority Delta:
10 10
10 10
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-s1p1c0 Priority Delta: 10 eth-s1p2c0 Priority Delta: 10 eth-s1p4c0 (Sync) 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: eth-s1p3c0 Priority Delta: eth-s1p2c0 (Internal) 192.168.2.2/24 Virtual Router: 2 Priority: 95 Hello Interval: 1 Backup IP: 192.168.2.3 Monitor Interfaces: eth-s1p1c0 Priority Delta: eth-s1p3c0 Priority Delta: 192.168.4.1/24
10 10
10 10
25
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-s1p1c0 Priority Delta: 10 eth-s1p2c0 Priority Delta: 10 eth-s1p4c0 (Sync) 192.168.4.2/24
Some VRRP configuration notes

1. 2. 3. 4. The Hello Interval, priority deltas, and authentication should be the same on all virtual routers. The priority delta on the secondary (95) should be numerically lower than the primary's priority (100). The backup IPs are what will be used in the routing configuration for clients and other routers. 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 (eths1p1c0). FireWallB will sense the failure of that interface because it will stop receiving VRRP Hello requests from 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 eths1p1c0 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
26
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. 2. 3. 4. 5. Disable VRRP on FireWallB, then FireWallA. 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. In Network Voyager, reconfigure the host address assignments on FireWallA (and FireWallB, if necessary) to reflect the new IP assignments for FireWallA. If this hasn't already been done, install new licenses on FireWallA. Do a fwstop and fwstart for the new licenses to take effect. 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. If you have encryption defined, regenerate the necessary encryption keys, as this will be required. Re-install the security policy. Configure Monitored Circuits on FireWallA. The configuration should look like this: 205.226.10.3/24
6. 7. 8.
eth-s1p1c0 (External)
Virtual Router: 10 Priority: 100 Hello Interval: 1 Backup IP: 205.226.10.1 Monitor Interfaces: eth-s1p2c0 Priority Delta: 10 eth-s1p3c0 Priority Delta: 10 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: 10 eth-s1p3c0 Priority Delta: 10
27
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-s1p1c0 Priority Delta: 10 eth-s1p2c0 Priority Delta: 10 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-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.1 Monitor Interfaces: eth-s1p1c0 Priority Delta: 10 eth-s1p3c0 Priority Delta: 10 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-s1p1c0 Priority Delta: 10 eth-s1p2c0 Priority Delta: 10 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
28
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. 3. 4. 5. On the primary, disable VRRP on all interfaces at the same time. Traffic will now flow through the secondary. Change the IP addresses on the primary. Change the IP addresses in the VPN-1/FireWall-1 object representing the primary. You will have to regenerate your encryption keys. 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.

How to setup HA VPN for a VPN-1 Appliance SecureKnowledge Solution ID: 36.0.2468192.2513640 What is VRRP Monitored Circuit?
SecureKnowledge Solution ID: 47.0.2688826.2541187 How long does it take for VRRP Monitored Circuits to converge?
SecureKnowledge Solution ID: 55.0.6517817.2665001 When testing VRRP MC by pulling an interface, the other interfaces do not let go of their IP addresses
SecureKnowledge Solution ID: 55.0.5928491.2651689 Which VRRP should one use?
SecureKnowledge Solution ID: 55.0.5928483.2651689 What is the RFC number for VRRP, and where is the RFC located?
SecureKnowledge Solution ID: 55.0.5928464.2651689 How should I configure my Ethernet switch to work with VRRP?
SecureKnowledge Solution ID: 55.0.5193914.2631768 Tools to monitor and troubleshoot VRRP in IPSO 3.X systems
SecureKnowledge Solution ID: 55.0.5194917.2632012 Can VRRP be used to back up a physical interface connected to a LAN with another physical interface connected to the same LAN?
SecureKnowledge Solution ID: 55.0.5928499.2651689 Can eth-s1p2 be used to backup eth-s1p1 on the same LAN?
SecureKnowledge Solution ID: 55.0.5928499.2651689 Why does VRRP not work when ipsrd crashes and comes back up in a certain configuration?
SecureKnowledge Solution ID: 55.0.5467833.2637542 IPSO 3.0x operating system does not send out VRRP HELLO packets.
SecureKnowledge Solution ID: 47.0.169000.2516436 Excessive VRRP Flapping (provides fix to ifm binary)
29
SecureKnowledge Solution ID: 36.0.174313.2473478 Why am I not able to ping the VRRP virtual IP address from the VRRP master router?
SecureKnowledge Solution ID: 55.0.5467843.2637542
30
VPN-1 Appliance Command Line Interface
newimage

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 of ipsofwd) 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 and newpkg commands
newimage and newpkg are used to installing new images/packages.
newimage
Syntax
newimage [[-i | -l localfile] [-R]] [-r imagename]
Options
parameter -i: -l -r -R: meaning Load a new image interactively Localfile: extract the new image from an extant file Imagename: specify imagename to run at next boot Use newly-installed image to run at next boot
31
newpkg
parameter -k
meaning 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 the transition 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. After booting from 3.3, enable the 3.3 VPN-1/FireWall-1 package using Network Voyager.
-v
verbose ftp
newpkg
Syntax
newpkg [options] Options
parameter -s server_ipaddr -l user -p password -m media_type -d -v -n newpkg -o oldpkg -i -h meaning The server IP address (if media is FTP/AFTP) User name (if media is FTP) User password (if media is FTP) Media type (CDROM/AFTP/FTP/LOCAL) Debug Verbose Full pathname of new package (eg: /pub/current/xxx.tgz) Full pathname of old package for upgrade (eg: /opt/xxx) Install only (do not activate) 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.
32
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.
meaning tcpdump per specific interface. Displays source and destination MAC addresses
parameter -i -e
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 telnet tcpudmp -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
33
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 harddrive 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.
Example
tcpdump -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 example
tcpdump -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 example
tcpdump -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)
34
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/xx atm 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 .. .. (DF) [tos 0x10] 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:
35
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 VPN1 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 help show meaning Displays help information. Shows categorized system information. Top-level iclid categories: bgp bootp dvmrp 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 quit ? Shows detailed raw information. Quit. Shows all possible command completions.
iclid command examples

command show ospf show ospf show route show route bgp 127 show b? meaning Shows OSPF summary information neighbor (s o n) Shows OSPF neighbor information Shows all routes Shows only BGP routes that start with 127 Shows all possible command completions for show b
How to display routing daemon status

1. 2. 3. Create a telnet session and log into the router. Type iclid. At the nodename prompt, type show? to display categories.
36
Syntax
V. ping, netstat and traceroute

These are standard and are documented in the Network Voyager on-line documentation package. Additional information on these standard UNIX utilities can be found at the FreeBSD Hypertext Man Pages.
VI. route
The route command is a generic UNIX command, with limited use on an IPSO system:
Syntax
route [ -nqv ] cmd [[ - ] args ] The cmd options are get, add, delete, dump, monitor, and flush The add, delete, and flush commands should not be used because the ipsrd daemon will immediately overwrite your efforts The get command does not work on IPSO The dump command is identical to netstat -rn (see V. ping, netstat and traceroute) The route monitor command reveals what the ifm() daemon detects in interface state changes. For example, when pulling the network interface cable from eth-s1p2, the following output was produced while running route monitor firewall-es[admin]# route monitor change ifphys eth-s2p2 phys index 2 pid 0 change ifnet eth-s2p2c0 link 4 phys index 2 pid 0 delete route INET atidvd route DIRECT_CLONE nexthop REJECT pid 0 delete route INET gameboy route DIRECT_CLONE nexthop REJECT pid 0 delete route INET shnserver route USER nexthop DEAD pid 123 delete route INET adsl-207-104-3-70.dsl.snfc21.pacbell.net route USER nexthop DEAD pid 123 The first four lines are for the change in the interface status from physically available to physically unavailable. Since the network this interface was attached to is no longer available, any route specifying a next hop to an IP address on this network is removed from the forwarding table
VI. Using the ipsrd command to troubleshoot network routing problem

The VPN-1 Appliance uses a routing daemon gated called ipsrd (IPSO Routing Daemon). This is a unique IPSO process that performs all routing functions. Various methods exist for looking at the operation of the routing. The IPSO specific commands are listed first, followed by the general UNIX commands: kill -INT ipsrd_PID It is possible to send an interrupt command to ipsrd in order to take a snapshot of its current state. The output provides very detailed information which can then be sent to Support for analysis. The Following procedure shows how this is done:
37
Viewing settings
nokia[admin]# nokia[admin]# information) nokia[admin]# nokia[admin]#
ps -aux | grep ipsrd (get the pid for ipsrd, eg. 115) kill -INT 115 (this will signal ipsrd to dump its current cd /var/tmp vi ipsrd_dump
VII. Using the ipsctl command line to set kernel variables

The ipsctl command can be used to view and set various kernel variables. Note that this is not a user tool and any changes to their variables should be verified by Support. At times however it may be necessary to change one of these settings.
Viewing settings
To use ipsctl in interactive mode to view settings use the ispctl -i command. testdown[admin]# ipsctl-i ipsctl Nov 19 05:40:36 > hw => ifphys > interface > kern > net explore: j, k down,up <, > left, right h help q quit Example of the view of a ethernet port: interface:eth-s1p1c0 addrmax 0 addrmin 0 altmtu 0 > family:inet > flags <up,phys_avail,link_avail,broa hdrmax 0 hdrmin 0 = index 2 label 0 lencaps lname mtu 1514 name eth-s1p1c0 phys eth-s1p1 > stats _____________________________________________________________
38
Using ipsctl in command line
Using ipsctl in command line

You can also view ispctl with the ipsctl -a command. Used with grep you can filter on specific settings.
Example
testdown[admin]# ipsctl -a | grep eth-s1p1c0 ifphys:eth-s1p1:log:eth-s1p1c0 = 2 interface:eth-s1p1c0:index = 2 interface:eth-s1p1c0:addrmin = 0 interface:eth-s1p1c0:addrmax = 0 interface:eth-s1p1c0:hdrmin = 0 interface:eth-s1p1c0:hdrmax = 0 interface:eth-s1p1c0:mtu = 1514 interface:eth-s1p1c0:altmtu = 0 interface:eth-s1p1c0:label = 0
Changing variables with ipsctl

Note 1: the changes will be lost on a reboot. To enable the change on a reboot the command would need to be added to the /vat/etc/rc.local file. Note 2: Please contact Support before you use one of these commands. In general, these would only be used as a workaround to a problem. Example: Here is a command to allow directed broadcasts. This is disabled by default. See Resolution 825 on the Nokia Support site http://support.nokia.com/ for more information on this specific example. ipsctl -w net:ip:forward:allow_directed:bcast 1
Example of FireWall related ipsctl variables and their meaning

net:ip:fw:registrations=1 net:ip:fw:de-registrations=0 net:ip:fw:input_calls net:ip:fw:output_calls /* means fw registration is true */ /* fw registed. */ /* how many fw input packet. */ /* # of output fw packet. */
39
Further information
Mission Statement
Further information
Check Point Support Information
Mission Statement
Check Point Worldwide Technical Services is committed to building strategic relationships with Check Point customers by providing consistent, dependable, high quality, measurable services which effectively utilize Check Point Software Technologies Ltd. products to meet network connectivity and security objectives.
Check Point Worldwide Technical Services General Process

Check Point Worldwide Technical Services utilizes a multi-tier support model for processing issue reports. When initial contact with Worldwide Technical Services is made, a Support Center Team Member will validate all contract information and gather details relevant to the question or issue. A unique trouble ticket number will be assigned and delivered to the designated contact, either verbally, or via electronic mail. This trouble ticket number will be used to track any given issue from initial contact to final resolution. If appropriate, an issue will be reproduced in our Test Lab. Additional testing and problem duplication may take place in a network laboratory environment. Further investigation, including additional troubleshooting or debugging activity may be required. Based on the results of the Test Lab investigation, an issue may be brought to resolution, or, if an anomaly is identified, escalated to Escalation Management. When an anomaly is identified, or an enhancement request is received, the issue will escalate via Escalation Management to Research & Development [Engineering].
Availability of Check Point Worldwide Technical Services

The Technical Support Call Center operates (subject to conditions beyond our control) seven (7) days a week, twenty-four (24) hours a day, three hundred sixty-five (365) days a year. Availability of Technical Support is subject to the conditions of the level of individual Support Contracts.
Platinum Support Gold Plus Support Gold Support Direct telephone and e-mail access to technical specialists for problem resolution, bug reporting, documentation clarification and technical guidance, 24 hours a day, 7 days a week. Direct telephone and e-mail access to technical specialists for problem resolution, bug reporting, documentation clarification and technical guidance, 24 hours a day, 7 days a week. Direct telephone and e-mail access to technical specialists for problem resolution, bug reporting, documentation clarification and technical guidance, on normal business days, Monday through Friday, during 6:00 am to 6:00 pm local time for the Americas, and Monday through Friday 8:00 am to 8:00 pm local time for the rest of the world.
Contacting Check Point Worldwide Technical Services by Telephone

Dial: 817-606-6600 An Automatic Call Direction System (ACD) will prompt you to select your customer support level. At this point, you will be directed to a Support Center Team Member. You will be asked for your organization's support number that will be given to you as part of your Support Registration Process. After it is verified that your Support ID is valid, the Support Center Team Member will create a trouble ticket tracking number in the Check Point database. You may be asked to provide or verify some of the following information. If it is not
40
Further information
Contacting Check Point Worldwide Technical Services by E-mail
possible to provide this information, Check Point may be hindered in the ability to bring resolution to an issue in a timely fashion. 1. Complete contact information, (name, title, company name, e-mail address, phone number, pager number, fax number, onsite phone number, time zone) for all parties involved in the issue. If the issue is related in any way to licensing, please provide certificate keys and purchase order numbers for the applicable product. Describe hardware platform(s) involved in this issue, including the amount of memory, disk space, and NIC card types (manufacturer and model). Describe the operating system(s) involved in this issue, including the version number and patch level information. (Include which service pack and Hotfixes for NT, which patches for Solaris, etc.). Provide a detailed description of the problem or issue, including any symptoms noted, any patterns seen (time of day or only certain users affected, etc) and any specific error messages received.
2. 3. 4.
The Support Center Team Member will then attempt to help resolve the issue. If the issue cannot be resolved via the phone, the issue will be transferred to the Check Point Test Lab. Once it has been determined that the issue cannot be resolved via the phone, you may be asked to submit some additional information which could include the following or other items: 1. Execute the $FWDIR/bin/fwinfo command on all FireWall-1 modules and the FireWall-1 management station in question, divert the output to a file, and ATTACH (do not embed), the file to an initial e-mail message. Provide a detailed description of the network topology including, but not limited to: physical network parameters, media and protocols. Location map (topology diagram) of all segment routers and transitional gateways. IP addresses of all router and gateway interfaces. General information about the network, including: approximate number of users, approximate number of simultaneous sessions per user, types of applications in use, etc. An electronic topology diagram is preferred - Visio or PowerPoint are good applications to use for this. If this is not feasible, a fax of hand drawn diagrams is an acceptable alternative, provided the IP addresses or Host ID information is legible. Provide a historical description of the problem or issue, from the customer's perspective, detailing chronology and troubleshooting efforts already completed. If FireWall-1 has been upgraded or "backed down" for any reason, please also detail which versions were involved. Provide any miscellaneous, related information. This would include debugging output, packet traces, core dump files, Dr. Watson error logs, FireWall-1 logs, etc.
2. 3. 4. 5. 6.
7.
8.
In the event Check Point is unable to diagnose and, where appropriate, resolve a problem through WTS access, then Check Point agrees to escalate the problem resolution in accordance with the Check Point escalation procedure. In all cases, Check Point will provide the customer a respective trouble ticket tracking number for all calls from the customer. In the event that Check Point assesses the call to be a non-Check Point defect or failure, Check Point will immediately contact the designated customer contact.
Contacting Check Point Worldwide Technical Services by E-mail

E-mail: support@ts.checkpoint.com All requests to open a trouble ticket will be routed to the Check Point WTS call-tracking database. A Support Center Team Member will send a response with a unique Trouble Number. The format for the unique Trouble Number will be as follows: ["n" is a numeric digit] TTnnnnnn: Trouble tickets created by Check Point WTS Call Center.
41
Further information
Problem Severity Definitions
All electronic mail transactions to and from Check Point WTS must be copied to or sent directly to support@ts.checkpoint.com, and must include the Support ID delimited by pound signs somewhere in the subject line, as illustrated in the following format: Re: FW-1 will not forward FTP packets on Tuesdays #SUPPORT ID# With regards to linking new mail to existing trouble tickets - as long as the engineer writes a reply to e-mails from Check Point WTS, the Trouble Ticket Signature should be in the body of the e-mail somewhere. Signatures are sent in all replies coming from Check Point and look something like this: Do not remove or modify this line: Signature#613132082756# PLEASE NOTE: If you do not receive an e-mail reply acknowledging receipt of your e-mail request for support within two (2) hours, you should assume that the e-mail link is down, and proceed to make a voice call to Worldwide Technical Services. In order to expedite the processing and resolution of individual issues, and to maintain and improve Check Point service quality, it is essential that certain information accompany any initial e-mail request. 1. When contact is initiated via electronic mail, the "Subject:" line should include a brief summary of the issue and must include the Support ID delimited by pound signs: Example: "FW-1 v4.0 Service Pack 3 installation question. #SUPPORT ID#" Complete contact information, (name, title, company name, e-mail address, phone number, pager number, fax number, onsite phone number, time zone) for all parties involved in the issue. If the issue is related in any way to licensing, please provide certificate keys and purchase order numbers for the applicable product. Describe the hardware platform(s) involved in this issue, including the amount of memory, disk space, and NIC card types (manufacturer and model). Describe the operating system(s) involved in this issue, including the version number and patch level information. (Include which service pack and Hotfixes for NT, which patches for Solaris, etc.). Provide a detailed description of the problem or issue, including any symptoms noted, any patterns seen (time of day or only certain users affected, etc) and any specific error messages received. Execute the $FWDIR/bin/fwinfo command on all FireWall-1 modules and the FireWall-1 management station in question, divert the output to a file, and ATTACH (do not embed), the file to an initial e-mail message. Provide a historical description of the problem or issue, from the customer's perspective, detailing chronology and troubleshooting efforts already completed. If FireWall-1 has been upgraded or "backed down" for any reason, please also detail which versions were involved.
2.
3. 4. 5. 6.
7.
Check Point understands that due to unusual circumstances, it may not always be feasible to include all of this information in an initial e-mail In order to provide better service, Check Point requests this information as soon as possible, as access to the appropriate data and information facilitates problem resolution. If it is not possible to provide this information, Check Point may be hindered in the ability to bring resolution to an issue in a timely fashion.
Problem Severity Definitions

Severity 1 error An error that renders product inoperative or causes the product to fail catastrophically; e.g. major system impact, system down. A reported defect in the licensed product which cannot be reasonably circumvented, in which there is an emergency condition that significantly restricts the use of the licensed product to perform necessary business functions. Inability to use the licensed product or a critical impact on operation requiring an immediate solution.
42
Further information
Software Versions Supported
Severity 1 error
An error that renders product inoperative or causes the product to fail catastrophically; e.g. major system impact, system down. A reported defect in the licensed product which cannot be reasonably circumvented, in which there is an emergency condition that significantly restricts the use of the licensed product to perform necessary business functions. Inability to use the licensed product or a critical impact on operation requiring an immediate solution. An error that substantially degrades the performance of the product or materially restricts business; e.g. moderate system impact, system hanging. This classification is a reported defect in the licensed product which restricts the use of one or more features of the licensed product to perform necessary business functions but does not completely restrict use of the licensed product. Ability to use the licensed product, but an important function is not available and operations are severely impacted. An error that causes only a minor impact on the use of the product; e.g. minor system impact, performance/operational impact. The severity level three defect is a reported defect in the licensed product that restricts the use of one or more features of the licensed product to perform necessary business functions. The defect can be easily circumvented. The error can cause some functional restrictions but it does not have a critical or severe impact on operations. A reported anomaly in the licensed product which does not substantially restrict the use of one or more features of the licensed product to perform necessary business functions. This is a minor problem and is not significant to operation. Anomaly may be easily circumvented or may need to be submitted to Research and Development as a request for enhancement.
Severity 2 error
Severity 3 error
Severity 4 error
Software Versions Supported

Check Point will provide Support to authorized, registered customer with active Support Contracts for the current and the immediately Previous Sequential Major Release of the Check Point Software. Previous Sequential Major Release is a release of product, which has been replaced, by a subsequent release of the same product. Notwithstanding anything else, Check Point will Support the previous sequential release only for a period of eighteen (18) months after release of the subsequent release. (That means that Check Point will only Support the older version of the Software for eighteen months after a new version comes out.)
Escalation Procedure
Regardless of the total elapsed time of an outstanding ticket, the point of escalation is initiated at the engineering level, escalated to the Team Lead, and followed by the Support Center Manager(s). Should an issue require managerial attention, any Technical Services team member will, upon request, connect customer to a manager directly. The formal manager escalation path for all Check Point office locations is as follows: Technical Services Team Leader Technical Services Manager, Corporate Manager, OEM Manager, Bench Test Manager, Escalations Manager Technical Services Director, Escalations Director Vice President-World Wide Technical Services
2000 Check Point Software Technologies Ltd. All Rights Reserved.
43
Further information
Nokia Support Site Access
Nokia support Information

Nokia Support Site Access
http://support.nokia.com Note: The support site requires a login username and password. Registration is on-line and requires a valid serial number. Registration can take up to 48 hours.
Or contact: Registration@iprg.nokia.com
Nokia contact numbers and information

Americas TAC: 1-888-477-9824 or 1-650-625-2525 EMEA TAC: + 44 (0) 208-564-8100 Email: support@iprg.nokia.com
44

ATRG Nokia Appliance

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

ATRG Nokia Appliance

Diunggah oleh

Hak Cipta:

Format Tersedia

Check Point VPN-1 Appliance Advanced Technical Reference Guide

Check Point 2000

VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000

Who should use this Guide

How to obtain the latest version of this Guide

VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000

VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000

IPSO The VPN-1 Appliance Operating System

IPSO The VPN-1 Appliance Operating System

IPSO design more secure

VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000

IPSO The VPN-1 Appliance Operating System

IPSO File System Layout

IPSO information gathering utility ipsoinfo

VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000

Upgrading a VPN-1 Appliance

Upgrading a VPN-1 Appliance

Before You Begin

Begin the Upgrade

VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000

Upgrading a VPN-1 Appliance

VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000

Upgrading a VPN-1 Appliance

IPSO 3.1, 3.1.1, and 3.1.2

IPSO 3.1, 3.1.1, and 3.1.2

IPSO 3.1.3, 3.1.4

VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000

Upgrading a VPN-1 Appliance

IPSO 3.1.3, 3.1.4

VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000

Upgrading a VPN-1 Appliance

IPSO 3.1.5, 3.2

IPSO 3.1.5, 3.2

VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000

Upgrading a VPN-1 Appliance

IPSO 3.1.5, 3.2

VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000

Upgrading a VPN-1 Appliance

IPSO 3.1.5, 3.2

VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000

Upgrading a VPN-1 Appliance

Boot Manager Upgrade

Boot Manager Upgrade

VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000

Upgrading a VPN-1 Appliance

Managing IPSO Configuration Sets

Managing IPSO Configuration Sets

Backup Configuration Information

VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000

Upgrading a VPN-1 Appliance

Backup Configuration Information

Upgrading VPN-1/FireWall-1 Packages

IPSO Version 3.0.x 3.1.x 3.2.x 3.3

VPN-1 Appliance Advanced Technical Reference Guide 4.1 August 2000

VPN-1 Appliance Common issues

Scenario #1 (Without NAT)

VPN-1 Appliance Common issues

Scenario #1 (Without NAT)

On the external Router

Middle FireWall Pair

On the internal Router

Scenario #2 (With NAT, and only in IPSO 3.3)

On the external Router