IPSO 4-2 MR9 Release Notes

Getting Started Guide andRelease Notes for

Check Point IPSO 4.2 MR9

Title Page

Build 111

Published September 2, 2010

2 Getting Started Guide and Release Notes for Check Point IPSO 4.2 MR9

© 2003-2009 Check Point Software Technologies Ltd.All rights reserved. This product and related documentation are protected by copyright and distributed under licensing restricting their use, copying, distribution, and decompilation. No part of this product or related documentation may be reproduced in any form or by any means without prior written authorization of Check Point. While every precaution has been taken in the preparation of this book, Check Point assumes no responsibility for errors or omissions. This publication and features described herein are subject to change without notice.

RESTRICTED RIGHTS LEGEND:

Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19.

TRADEMARKS:

Refer to http://www.checkpoint.com/copyright.html for a list of Check Point trademarks

For third party notices, see http://www.checkpoint.com/3rd_party_copyright.html.

www.checkpoint.com

Worldwide HeadquartersCheck Point Software Technologies, Ltd.

5 HaSolelim StreetTel Aviv 67897, Israel

Tel: 972-3-753-4555Fax: 972-3-624-1100

email: [email protected]

U.S. HeadquartersCheck Point Software Technologies, Inc.800 Bridge ParkwayRedwood City, CA 94065Tel: 800-429-4391; 650-628-2000Fax: 650-654-4233

http://www.checkpoint.com/3rd_party_copyright.html

http://www.checkpoint.com/3rd_party_copyright.html

www.checkpoint.com

Contents

1 What’s New in Check Point IPSO 4.2 MR9 . . . . . . . . . . . . . . . . . 5Enhancements in IPSO 4.2 MR9 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Enhancements in IPSO 4.2 MR8b . . . . . . . . . . . . . . . . . . . . . . . . . . 6Enhancements in IPSO 4.2 MR8a . . . . . . . . . . . . . . . . . . . . . . . . . . 6Enhancements in IPSO 4.2 MR8 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Enhancements and Fixes in IPSO 4.2 MR7. . . . . . . . . . . . . . . . . . . 6Enhancements and Fixes in IPSO 4.2 Build 096 . . . . . . . . . . . . . . 11Enhancements and Fixes in IPSO 4.2 Build 089 a03 and Earlier . 19

2 New Features in Check Point IPSO 4.2 . . . . . . . . . . . . . . . . . . 103SecureXL Enabled by Default . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Enhanced Password Configuration . . . . . . . . . . . . . . . . . . . . . . . 104High-Availability Enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . 105Support for Check Point Local Logging on Optional Disks. . . . . . 108Enhancements for Time Configuration. . . . . . . . . . . . . . . . . . . . . 111Enhanced Traffic Management (QoS) . . . . . . . . . . . . . . . . . . . . . 111Voyager and CLI Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . 117SNMP Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Logging Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Enhancements for Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 120Enhancement for OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Link Aggregation Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Ethernet Link Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Enhancement for GigE Interfaces <PR 56460> . . . . . . . . . . . . . . . . . . . . 126Modem Dialback Enhancement . . . . . . . . . . . . . . . . . . . . . . . . . . 127GTP Acceleration with SecureXL . . . . . . . . . . . . . . . . . . . . . . . . . 127

Getting Started Guide and Release Notes for Check Point IPSO 4.2 MR9 3

Support for Long Range Ethernet NICs . . . . . . . . . . . . . . . . . . . . 128Mobile IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Transparent Mode on IP225x <PRs 57780, 57781, 57783> . . . . 128

3 Performing the Initial Configuration . . . . . . . . . . . . . . . . . . . . 131Using DHCP to Configure the System . . . . . . . . . . . . . . . . . . . . . 132Using the Console to Configure the System . . . . . . . . . . . . . . . . 135Registering the IP Appliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Performing Additional Configuration . . . . . . . . . . . . . . . . . . . . . . 139

4 Upgrading to Check Point IPSO 4.2 . . . . . . . . . . . . . . . . . . . . 145Downloading Check Point IPSO and Related Files . . . . . . . . . . . 147Using Check Point Horizon Manager to Install IPSO and Packages . .

148Before You Install Check Point IPSO from Check Point Network Voyag-

er or the Command Shell. . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Installing Check Point IPSO 4.2 from Check Point Network Voyager or

the Command Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Installing and Activating Packages. . . . . . . . . . . . . . . . . . . . . . . . 161Modem Country Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

5 Supported Platforms, Versions and Memory Configurations 173Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Supported Check Point Versions . . . . . . . . . . . . . . . . . . . . . . . . . 175Supported Memory Configurations <PRs 45068, 45119, 48954> 175. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

6 Resolved Issues, Known Limitations and Configuration Tips 179Resolved Issues in IPSO 4.2 MR9. . . . . . . . . . . . . . . . . . . . . . . . 180Known Limitations and Configuration Tips. . . . . . . . . . . . . . . . . . 183


1 What’s New in Check Point IPSO 4.2 MR9

Check Point IPSO 4.2 MR9 (Build 111) is a new release of the IPSO 4.2 operating system used on Check Point IP security platforms. This chapter describes the enhancements and fixes that Check Point has added to IPSO 4.2 since its original release. See:

Enhancements in IPSO 4.2 MR9 on page 6Enhancements in IPSO 4.2 MR8b on page 6Enhancements in IPSO 4.2 MR8a on page 6Enhancements in IPSO 4.2 MR8 on page 6Enhancements and Fixes in IPSO 4.2 MR7 on page 6Enhancements and Fixes in IPSO 4.2 Build 096 on page 11Enhancements and Fixes in IPSO 4.2 Build 089 a03 and Earlier on page 19

For information about the new features in the original release, see Chapter 2, New Features in Check Point IPSO 4.2 on page 103.



Enhancements in IPSO 4.2 MR9IPSO4.2 MR9 (Build 111) resolves a number of issues. See Resolved Issues in IPSO 4.2 MR9 on page 180.IPSO4.2 MR9 (Build 111) adds support for FireWall-1 GX. See GTP Acceleration with SecureXL on page 127.

Enhancements in IPSO 4.2 MR8bIPSO4.2 MR8b (Build 106a05) adds support for the IP282 platform.

Enhancements in IPSO 4.2 MR8aIPSO4.2 MR8a (Build 106a04) adds support for R65 HFA 70.In addition, when the IP 150 platform is powered off, traffic is no longer forwarded between ports. <00257403>

Enhancements in IPSO 4.2 MR8IPSO4.2 MR8 (Build 106a02) fixes an issue which may occur on some IP1280/1285 or IP2450/2455 systems, resulting in persistent false over-temperature or voltage alarms being reported, which may further cause packet loss and resulting performance degradation.

Enhancements and Fixes in IPSO 4.2 MR7IPSO 4.2 MR7 includes the following enhancements and fixes:

Support for 10Gb and 1Gb Ethernet CardsEnhancement for Auto Detect Support in the Endpoint Connect VPN ClientEnhancement for PIM Over NAT <00486182 >


Enhancements and Fixes in IPSO 4.2 MR7

Enhanced Configuration Summary Tool (ECST)

Support for 10Gb and 1Gb Ethernet CardsThis release of IPSO supports the release of 10 Gigabit Ethernet and 1 Gigabit Ethernet cards as optional add-ons for the following Check Point IP Appliance platforms:

IP2450IP1280IP690

These cards deliver high throughput for network environments that do not require the specialized acceleration offered by Check Point ADP modules.

10 Gigabit Ethernet Cards Check Point offers new dual-port 10 Gigabit Ethernet cards in two versions:

Network interface card with XMC connectors for the IP2450 and IP1280 appliances Network interface card with PMC connectors for the IP690 appliance.

Both versions include sockets that accept interchangeable SFP+ transceivers. These cards can help your network meet the increasing demands of transporting content types such as video and VoIP or accommodate virtualization.

1 Gigabit Ethernet Cards Check Point offers new four-port 1 Gigabit Ethernet cards in two versions:

Network interface card for the IP1280 and the IP2450 appliances with integrated RJ-45 connectorsNetwork interface card for the IP1280 and IP2450 appliances with sockets that accept interchangeable SFP transceivers available in 1000Base-T, 1000Base-SX, and 1000Base-LX versions



These cards implement a new design that leverages the latest technological advances and connect directly to the PCI-e data bus to improve the speed and efficiency of moving packets between the interfaces and the multiple CPU cores.

Enhancement for Auto Detect Support in the Endpoint Connect VPN Client

This IPSO release provides enhanced support for the Endpoint Connect VPN client (available since NGX R65 HFA 40): The Auto Detect and Connect feature of the client is now supported.Whenever the VPN gateway or client’s location changes, the Endpoint Connect client autodetects the best method to establish a connection, using either NAT-T (UDP port 4500) or Visitor mode (TCP port 443), intelligently auto-switching between the two modes as necessary.

Enhancement for PIM Over NAT <00486182 >

PIM Sparse mode can be used with Network Address Translation (NAT). For configuration details, see the Network Voyager Reference Guide for IPSO 6.2 at http://supportcontent.checkpoint.com/documentation_download?ID=10293

Enhanced Configuration Summary Tool (ECST)The Enhanced Configuration Summary Tool (ECST) allows you to capture your current IPSO configuration, log files, core dumps and other information in a single file that can be sent to Check Point customer support for analysis. Typically, you would run ECST if you have opened a case with Check Point support and you have been asked to provide an ECST file.

The ECST for IPSO 4.2 is available as a separately installable IPSO package from http://supportcenter.checkpoint.com/file_download?id=10093


http://supportcontent.checkpoint.com/documentation_download?ID=10293

http://supportcenter.checkpoint.com/file_download?id=10093

Enhancements and Fixes in IPSO 4.2 MR7

After installing the package, you can access the Voyager pages for this feature by clicking Tools > ECST Configuration at the bottom of the Voyager navigation tree.When you run ECST, you can include any or all of the following information in the output file:

Offline Network Voyager pages—captured Network Voyager pages that show your current configuration and that can be viewed offline by Check Point customer support.You must supply your user name and password for ECST to capture the Network Voyager pages. To ensure that all the configuration information is captured, you should have at least read-only access to all IPSO features.When you include offline Network Voyager pages, ECST saves your current configuration before it captures the pages.Firewall information—firewall status, objects, tables, and diagnostics, as captured from utilities such as cpinfo, cpstat, and fw tab.IPSO information—captured output from the utilities listed below. :

IPSO log files—copies of the syslog log files, httpd access logs, httpd error logs, cron logs, and other logs.IPSRD/Core dumps—copies of the configuration files in /config, user directories in /var/emhome, IPSRD and core dumps, and firewall logs.

date arp -a

uname -a vmstat -mis

ifconfig -v -a dbget -rv dynamic

ps -auxw ipsctl -a

df -k ntpdc -pn

pstat -ks ls -l

netstat



All ECST output files are stored in /opt/ecst_output on the appliance. Because the ECST output files can be quite large if you include the Network Voyager offline pages, Check Point recommends that you do not keep more than three output files on your appliance at a time.You can also run ECST from the IPSO shell, using the command:# ecst [ -cfhilv ]If you include no options, ECST collects information based on the configuration in its current configuration file. The contents of this file are determined by the Service Summary selections in Network Voyager. If no configuration file exists, ECST collects all information.If you specify options, ECST ignores the configuration file and collects just the information specified by the options.The options are described in Table 1.

The files produced by ECST are in the /opt/ecst_output directory.

Table 1 ECST Options

Option Description

-c Specifies that the core dump files, configuration files, and user home directories should be collected.

-f Specifies that firewall information should be collected.

-h Displays help for the ecst command.

-i Specifies that the output of various utilities should be captured (same content as the legacy ipsoinfo utility)

-l Specifies that the log files should be collected.

-v Specifies that Network Voyager pages should be captured for offline viewing.


Enhancements and Fixes in IPSO 4.2 Build 096

Enhancements and Fixes in IPSO 4.2 Build 096IPSO 4.2 Build 096 includes the following enhancements and fixes:

Enhancements for ADP StabilitySupports ADP Modules with IP2450 and IP1280Enhancement for Argentina Time Zone Changes <PR 81415>Enhancement for Cluster Stability <PR 82376>Enhancement for Hiding Hash Values <PR 81040>Enhancement for Not Fragmenting VPN Traffic <PR 78720>Single License VRRP Not Supported <PRs 78496, 82026>ADP Core File Name ChangeFix for Issue with BGP Route Aggregation <PR 79293>Fix for Issue with Malformed Packets <PR 81955>Fix for Issue with Graphical SSH Login <PR 69588>Fix for Issue with httpd Configuration <PR 79944>Fix for Proxy ARP Display Issue <PR 81455>Fixes for CrashesFix for Single-Node Cluster in Forwarding Mode <PR 81454>

The numbers in angle brackets after the headings in the following sections are the tracking numbers for the issues in Check Point’s internal database of problem resolutions. Reference the appropriate number if you contact Check Point about any of these items.

Enhancements for ADP StabilityIPSO 4.2 Build 096 includes a number of improvements to enhance the stability of Check Point Accelerated Data Path (ADP) services modules. Check Point ADP services module are designed for large and medium-sized organizations that need to respond to evolving Internet traffic patterns yet do not want the major disruption of a platform upgrade. ADP services modules let platforms offload some processing from the CPU(s) to hardware modules



that are optimized for forwarding traffic using Check Point’s SecureXL. This “appliance within an appliance” architecture allows the platform CPU(s) to dedicate more resources to nonaccelerated (slow path) traffic and deep packet inspection. IPSO 4.2 supports ADP services modules with the following platforms:

IP2450IP1280IP1260IP1220IP690IP560

Supports ADP Modules with IP2450 and IP1280IPSO 4.2 MR7 supports the use of Check Point ADP services modules with the Check Point IP2450 and IP1280 network security platforms. The modules install in the front-facing 6U card slots on the platforms and are optional add-ons for these systems.

NoteMake sure that IPSO 4.2 MR7 is running on your IP2450 or IP1280 before you install an ADP module. Previous releases of IPSO 4.2 do not recognize ADP modules on these platforms.

The ADP modules are available in 10 Gigabit Ethernet and 1 Gigabit Ethernet versions. The IP2450 supports two ADP modules, and the IP1280 supports one ADP module. You can install any combination of modules in the IP2450. For example, each of the following combinations are valid in an IP2450:

two 1 Gigabit Ethernet ADP modulestwo 10 Gigabit Ethernet ADP modulesone 10 Gigabit Ethernet ADP module and one 1 Gigabit Ethernet ADP module



The ADP modules include eight high-performance network processing unit cores and 2GB of RAM.

1 Gigabit Ethernet VersionsTwo versions of the 1 Gigabit Ethernet modules are available:

12-port Small Form-factor Pluggable (SFP). You can install 1000Base-SX, 1000Base-LX, and 1000Base-T transceivers in any combination in this module.12-port 10/100/1000Base-T RJ-45 connectors.

10 Gigabit Ethernet VersionEach 10 Gigabit Ethernet module provides three sockets that you can populate with the following transceivers:

10GBase-SR (300m) XFP optical transceiver10GBase-LR (10km) XFP optical transceiver

You can combine transceiver types in one ADP module. For example, you can install one 10GBase-SR transceiver and two 10GBase-LR transceivers in the same module.

Enhancement for Argentina Time Zone Changes <PR 81415>

IPSO 4.2 MR7 includes an enhancement to support recent time zone changes in Argentina.

Enhancement for Cluster Stability <PR 82376>

If an IP cluster is under a very heavy load, it can experience a series of cluster transitions (changes of master) as the nodes attempt to accommodate the



traffic. IPSO 4.2 Build 096 includes an enhancement that can reduce or eliminate these cluster transitions.If your cluster experiences frequent transitions under heavy load or if the CPU utilization of the nodes is consistently very high, enter the following IPSO CLI command:set cluster aggressive-heartbeat <yes|no>

Executing this command causes the nodes to double the number of heartbeat packets they exchange to verify each other’s status. Enter the following CLI command to view the setting for this option:show cluster aggressive-heartbeat

Enhancement for Hiding Hash Values <PR 81040>

If you enable the System Configuration Audit Log option on a system running a previous build of IPSO 4.2 and then create or configure any password, encryption key, SNMP community string, and so on, IPSO stores an encrypted hash representation of the new value (and previous value, if any) in the audit log. Though they are encrypted, it is possible that an attacker could decrypt the hashes if they could gain access to them.IPSO 4.2 Build 096 enhances system security by not storing these hashes in the audit log. For example, hashes of passwords or keys for user accounts, routing protocols, SNMP, DDNS server, FTP server, and so on are not stored in the system configuration audit log.

Enhancement for Not Fragmenting VPN Traffic <PR

78720>

Some network devices do not correctly process fragmented encrypted packets. With IPSO 4.2 Build 096, you can solve this problem by configuring your Check Point platform so that it will not fragment VPN traffic. To do so, enter the following command at the IPSO shell prompt:ipsctl -w net:ip:es:esp_df 1



Single License VRRP Not Supported <PRs 78496, 82026>

With previous builds on IPSO 4.2, you can configure both members of a VRRP pair to use a single Check Point license. This feature is not compliant with the Check Point EULA and does not appear in Build 084 and later. The feature is no longer supported with builds previous to 084, and customers that use it are urged to correct their configurations. If you use Single License VRRP and upgrade to Build 084 or later, disable the feature before you upgrade. If you do not disable it prior to upgrading, perform the following procedure at the IPSO shell prompt after upgrading:1. Enter

dbset process:licensed

2. Enterdbset :save

3. Reboot the platform.If you do not disable Single License VRRP before upgrading to Build 096, IPSO displays a console message indicating that Check Point no longer supports this feature when you boot the system. After you perform the above procedure, the message no longer appears.

ADP Core File Name Change The naming scheme for the core files that are produced when an ADP subsystem fails is changed in Build 096.These core files are now named using the following convention: kcore-u<0|1>s<1|2>-mm.dd.yyyy-hhmmss.Z

Fix for Issue with BGP Route Aggregation <PR 79293>

On systems running a previous build of IPSO 4.2, The IPSO routing daemon (ipsrd) can restart under certain circumstances when route aggregation is



configured to aggregate routes learned from BGP. The specific circumstances are:

Route aggregation is configured.The system receives a TCP/IP packet containing more the one BGP route update from the same peer and two of the route updates advertise reachability/unreachability to the same network prefix.The network prefix is configured as a contributing prefix to the aggregate route.

Build 096 fixes this problem.

Fix for Issue with Malformed Packets <PR 81955>

Systems running previous builds of IPSO 4.2 can panic if NAT is enabled and they attempt to process certain malformed packets that could be sent in an attempt to attack the network. Build 096 prevents this from happening by dropping these specific packets when they are received. Because these malformed packets are dropped on input, you cannot see if any packets of this type have been received by viewing the firewall logs. To learn whether your system has received any packets of this type, enter the following command at the IPSO shell prompt:ipsctl net:ip:rx:stats:badl4hlen

Fix for Issue with Graphical SSH Login <PR 69588>

You can configure IPSO systems to display a banner message that appears on the login page. If you use a graphical SSH-based application (such as WinSCP) to log into a system with this feature enabled, you might see a dialog box that displays the banner message, depending on the application.If you disable the banner message on a platform running a previous build of IPSO 4.2, the system displays an empty dialog box when you log in with a graphical SSH-based application that displays the banner in a dialog box. You



must click the Continue button in the empty dialog box to gain access to the system.Build 096 does not display an empty dialog box if the banner message is disabled.

Fix for Issue with httpd Configuration <PR 79944>

If you configure httpd in a previous build of IPSO 4.2 to listen only on a specific interface instead of all the active interfaces, IPSO hangs if a user attempts to access Voyager through this interface by using SSH port forwarding. (Some customers use this approach as part of a configuration that requires Voyager users to connect through an SSH tunnel.)Build 096 fixes this problem.

Fix for Proxy ARP Display Issue <PR 81455>

If you create multiple proxy ARP entries that use the same MAC address on a system running a previous build of IPSO 4.2, Voyager does not show the entries properly on the Configuration Summary page.This is a display issue only and is fixed in Build 096.

Fixes for CrashesPrevious builds of IPSO 4.2 can panic and crash while executing function net_sc_intr() as a result of a rare problem related to SecureXL. Build 096 fixes this issue. <PR 80459>

IPSO Build 081 a03 includes a fix for an issue in which a system with SecureXL enabled might crash and reboot if it accelerates an encapsulated UDP connection. (Encapsulated UDP is typically used to route IPSec traffic through a NAT gateway.) However, this problem can still occur with these builds under certain circumstances. <PRs 77354, 81261>

Build 096 includes another fix for this issue.



Build 096 also fixes a problem that can cause any system running a previous build of IPSO 4.2 to panic and crash while executing function rlist_free(). <PR 80610>

Fix for Single-Node Cluster in Forwarding Mode <PR

81454>

If you have a single-node cluster with forwarding mode enabled on a system running a previous build of IPSO 4.2, a problem can occur if an interface is deactivated and reactivated or disconnected and reconnected. In this situation, IPSO stops sending gratuitous ARP replies from the affected interface, which can cause the ARP table entry for the interface to be deleted from an attached network switch. If this happens, traffic will not be sent to that interface.This problem occurs only with single-node clusters and only if the cluster uses forwarding mode. Build 096 fixes the issue.


Enhancements and Fixes in IPSO 4.2 Build 089 a03 and Earlier


IPSO 4.2 MR7 also includes the following enhancements and fixes added in previous builds of IPSO 4.2:

Supports Release of T1 Card for IP390Enhancement for Check Point Logging <PR 80640>Routing-Related FixesFixes for Policy-Based RoutingFix for IP225x ADP Issue with Two-Port GigE NICs <PR 80243>Fix for Packet Drops on GigE Interfaces <PR 79543>Fix for Incorrect Syslog Interface on Flash-Based Platforms <PR 79522>Fix for Link Redundancy Group Containing Link Aggregation Interface <PR 80451>Fix for Panic Caused by Memory Reports <PRs 76052, 77253>Fixes for Rare Panics <PRs 71392, 79194, 80039>Fix for Time Change Problem <PR 31760>Fix for IP260/IP265 Temperature Sensing Issue <PRs 57833, 70990>Fix for Automatic Transfer of Archive Files <PR 77416>Fix for Adding Loopback Interface with the CLI <PR 78343>Fix for Group for Daemon User <PR 80410>Fix for SNMPv3 Security Vulnerability <PR 78753>Fixes for High-Availability FeaturesFixes for ADP IssuesFix for IP225x ADP Issue <PR 73980>Fix for SMF NIC Installation <PR 79049>Fix for 10 GigE Interface Not Reactivating <PR 53163>Fix for Eight Port NICs in IP225x <PR 78948>Fix for Rare IP225x Panic <PR 73979>



Fix for Rare ipsrd Crash <PR 77675>Fix for SecureXL and UDP Encapsulation <PRs 77836, 79050>Fix for SecuRemote/SecureClient Connections <PR 75401>Supports IP150Enhancement for Alternate DNS Server OptionFix for FTP Problem <PR 71395>Fix for Disk Mirroring <PR 66843>Fix for Disk Mirror Error Message <PR 58524>Fix for IP225x ADP Failure <PRs 73327>Fix for Crash Related to SecureXL and UDP Encapsulation <PRs 59921, 72977>Fix for Rare SecureXL-Related Crash <PR 64218>Support for ADP Modules with IP690Enhancement for Identifying Disk-Based Platforms <PR 70490>Fix for SSL-Related Security Vulnerability <PR 71013>Fix for ipsrd Crash <PR 66539>Fix for Boot Issue with IPSO 4.2 Build 051 <PR 67063>Fix for Issue with NAT and Cluster IP Address <PR 69063>Fix for VPN-Related Fragmentation Issue <PR 69248>Fix for Issue with Build 051 and Specific NICs <PR 71317>Fix for Disk Mirror Issue with IP12xx <PR 69998>Fix for Compact Flash Corruption after Panic on Flash-Based Systems <PR 61949>Fix for Misidentified PCMCIA Slots <PR 70120>Supports IP1280Enhancement for Static Multicast RoutesEnhancement for Redundant Switches <PR 65263>Enhancement for MSS for DVMRP and GRE Tunnels <PR 58611>Enhancement for SSL Support <PR 63970>



Enhancement for Anti-virus and URL Filtering on VLANs <PR 58499>Enhancement for Venezuela Time Zone Change <PR 67013>Fixes for High-Availability FeaturesRouting-Related FixesFixes for Issues Specific to IP225x PlatformsNAT-Related FixesFix for Upgrade Issue <PR 61391>Fix for Panic Caused by Link Aggregation <PR 67714>Fix for VPN-Related Issue <PRs 62688, 65913>Fix for VPN Accelerator Statistics Issue <PR 56021>Fix for Proxy ARP Issue <PR 58737>Fix for User Names <PRs 60154, 62089>Fix for IP260/IP265 Latency Issue <PR 57833>Fix for SNMP ifOutUcastPkts Counter <PRs 49664, 57262, 63488>Fix for AUX Serial Port <PR 61397>Fix for RAID Disk Issue on IP2450 <PR 65463>Supports Release of ADP ModulesFixes for IP Clustering on IP225x <PRs 59713, 59743, 60834, 61054, 61057, 61131, 61394, 61946, 62288, 62841, 62892, 62964, 62965, 62988, 63017, 63113, 63142>Enhancement for NAT with Transparent Mode <PR 59274>Enhancement for IP2255 and IP2450 Core Dumps <PR 60630>Enhancements for Storing Core Files <PRs 56989, 57336>Enhancement for Policy Based RoutingEnhancement for RIP Route Tags <PR 56709>Supports IP2450Routing EnhancementsFix for shutdown Command <PR 58951>Fix for IP26x Battery Error Message <PR 59228>



Fix for Interface-Related Crash <PR 59635>Fix for Rare Memory Issue <PR 58968>Fix for Panic on IP225x Halt or Reboot <PRs 58965, 59158, 59161, 59162>Supports IP690Supports Flash-Based IP290Memory Enhancement for IP350 <PR 58785>Fix for IP290 VPN Performance Issue <PR 58383>Fix for IP IP290 Cluster Issue <PRs 58262, 58651>Performance Fix for Disk-Based PlatformsFixes for IP225x ADP Issues <PRs 57761, 58051>Fix for IP225x Crash <PRs 58602, 58730>Fix for VPN-Related Panic <PR 58853>Fix for High CPU Utilization <PR 58683>Fix for GRE Tunnels <PR 58838Fix for Excessive Error Messages <PR 58808>Supports IP290Fix for Issue with RADIUS and Clusters <PRs 57619, 58428>Fixes for Cluster Reboots <PRs 58355, 58398>Fixes for IP225x PanicsFix for IP225x Fiber GigE Link Issue <PR 57916>Fix for IP225x Display Issue <PR 58151>Fix for Encryption-Related Crash on IP1220/IP1260 <PR 57918>Fix for Issue with Hardware Acceleration Statistics <PR 57389>Fix for IP260 Shutdown Issue <PR 58018>Fix for PPPoE-Related CLI Command <PR 57517>Transparent Mode Supported on IP225x <PRs 57286, 57780, 57781, 57783>Enhancement for Daylight Savings Time <PR 58031>



PIM Supported with Cluster Forwarding Mode <PR 58060>Fixes for Security VulnerabilitiesFix for Issue with Fresh Installation <PR 57892>Fix for Crash Caused by Port Address 0 <PRs 56726, 57988>Fix for Cluster Master Reboot <PR 57819>Fix for Issue with VRRP and Transparent Mode <PR 57930>Fix for SecureXL-Related Diagnostic Command <PR 58017>

Supports Release of T1 Card for IP390IPSO 4.2 Build 089 a03 and later supports the release of a Check Point T1 card as an optional add-on for the IP390 to support WAN connectivity for this platform.

This PMC-format interface card provides up to1.5 Mbps of throughput and has four T1 ports. This allows you to connect a single IP390 to four remote locations using industry-standard protocols such as PPP (Point-to-Point), HDLC (High-Level Data Link Control) and Frame Relay. The card occupies a single slot in an IP390.

Enhancement for Check Point Logging <PR 80640>

IPSO 4.2 Build 089 a03 and later introduces a new feature that permits you to eliminate the Check Point firewall debug messages that appear on the console by redirecting them to /dev/null. It also allows you to redirect them to a user-specified file or to the syslog server instead of eliminating them entirely.This new feature is configured through Network Voyager only. It is available only when a Check Point package is installed and enabled.



To configure Check Point logging1. In the Network Voyager navigation tree, click Firewall and Other

Packages > Check Point Log Configuration.2. To enable Check Point logging redirection, select On for Daemon

Enabled.3. Fill out the options on the page as follows:

To redirect to a file—under File Logging Options, select On for the Log to file option and change the other options from their default settings as needed.

CautionIf you redirect messages to a file on a flash-based system, Check Point recommends that you leave automatic file rotation enabled. This option ensures that the amount of disk space used by the stored messages never exceeds a set maximum. If you disable file rotation, the log file size grows indefinitely, and you must manually manage the file to ensure you will not run out of disk space.

Because version R55p of the Check Point firewall does not support file rotation, Check Point recommends you do not redirect firewall messages to a file if you are using version R55p.

To redirect to syslog—under Syslog Logging Options, select On for the Log to syslog option and change the other options from their default settings as needed. You must also set the Log to file option to Off.

NoteTo send redirected Check Point log messages to a remote server, you must also enable remote logging on the System Logging Configuration page (System Configuration > System Logging).

To redirect to /device/null—select Off for both the Log to file and the Log to syslog options.



4. Click Apply.Table 2 describes the options for Check Point logging configuration in more detail.Table 2 Check Point Logging Configuration Options

Option Description

Daemon Enabled Select On to enable redirection of Check Point log messages.To stop redirection of the Check Point log messages, select Off. None of the other options on this page take effect if Off is selected.

Default: Off

CP Log Buffer Size (KB) Specify the size in kilobytes of the buffer allocated within Check Point's kernel module for log entries.

Default: 128Range: 0–32768

Log to file Select On to enable redirection of the log messages to a file. Set this option to Off if you want to redirect messages to syslog or to /dev/null.

NoteCheck Point recommends that you do not redirect firewall messages to a file if you use Check Point firewall version R55p.

Default: On

Log file name Specify the full path name of the file in which you want the logs to be stored.

Default: /var/log/cpdebug.txt



File rotation count Specify the total number of files that will be used for file rotation as log files are filled. Specifying 0 prevents file rotation.

NoteFile rotation is not supported for version Check Point firewall version R55p.


File rotation size (MB) Specify the size of a log file in megabytes. When the log file reaches this size, it is rotated. This option has no effect if the File rotation count option is 0.


Log to syslog Select On to enable redirection of the log messages to syslog.

Table 2 Check Point Logging Configuration Options

Option Description



Routing-Related FixesThis section explains the fixes in this build related to routing features in IPSO.

Tag name Enter a short string that will be included in the message portion of the syslog entry. The tag is typically used to identify the process that generated the log entry.

Default: cplogger

Facility/Severity Select the facility and severity assigned to all log entries created by redirected Check Point log messages:

• Facility is one of the 16 traditional UNIX facilities that indicate the source of the log entry.

Avoid using the Auth or Kernel facilities, since most messages from these facilities are automatically sent to the console.

Default: Daemon

• Severity (also known as the priority) indicates the seriousness of the error or condition that the log entry describes.

Check Point recommends that you use either Notice or Warning severity. Lower severity levels (Info or Debug) are often dropped by the syslog server to avoid having a large number of unnecessary log entries. On the other hand, higher severity levels (Error and above) are automatically sent to the console.

Default: Notice

Table 2 Check Point Logging Configuration Options

Option Description



Fix for BGP Handling of Advertisements <PR 66564>

With previous builds of IPSO 4.2, a BGP speaker terminates the peering when it receives an Open message that advertises capabilities it does not recognize.With Build 089 a03 and later, BGP fully complies with RFC 3392, which provides a graceful way for BGP speakers to handle unrecognized capabilities without terminating peering.

Fix for PIM Issue <PR 80756>

With previous builds of IPSO 4.2, a problem occurs if you configure Sparse-Mode PIM in the following way. 1. You initially enable the Check Point platform as a candidate rendezvous

point (RP) but do not configure any multicast group addresses as the local RP-set for the candidate RP.Because you did not configure any multicast addresses, the default group address for the local RP-set is 224/4 (entire multicast range).

2. You later configure a specific multicast group address for the local RP-set.

In this circumstance, IPSO continues to advertise group-to-RP mappings for the entire multicast range instead of advertising them only for the multicast group address that you configured in step 2. Multicast traffic will still reach the appropriate hosts because the group address you configured is a subset of the entire multicast range.Build 089 a03 and later fixes this problem. When you configure a specific multicast group address for the local RP-set with this build, IPSO advertises group-to-RP mappings only for the configured group range, and obsolete mappings for 224/4 for which the Check Point system previously sent a bootstrap message will eventually time-out on all the connected routers.

Fix for PIM with Clustering Issue <PR 80414>

If you use PIM in an IP cluster running a previous build of IPSO 4.2 and enable IGMP snooping on a connected switch, the cluster members might



stop forwarding multicast traffic to hosts connected to that switch. (IGMP snooping is used in combination with the Multicast with IGMP cluster node to isolate traffic that is sent to the cluster from the rest of the network.)This problem does not occur on the cluster master—that node does not stop forwarding multicast traffic to switches with IGMP snooping enabled. Build 089 a03 and later fixes this problem. Cluster members forward multicast traffic to hosts connected to switches with IGMP snooping enabled as expected.

Fixes for Policy-Based RoutingThis section explains fixes in this build related to policy-based routing (PBR).

Deleting PBR Table Used by Access List <PR 77780>

When you use PBR, you create routing tables of static routes and direct traffic to the appropriate tables by using an access control list. Previous builds of IPSO 4.2 allow you to delete a policy-based routing table even if it is used by an access control list. If you do so, you might see console or log messages similar to the following:[LOG_ERR] pbr_xlate[1169]: File pbr_xlate.c:947 Failed to update routing instance table - Device busy [LOG_ERR] pbr_xlate[1169]: File pbr_xlate.c:1351 Commit changes to kernel failed. [LOG_ERR] xpand[1143]: Translator /bin/pbr_xlate was stopped during execution.

In addition, any further changes you make to policy-based routing might not take effect. For example, if you delete a policy-based routing table that is used by an access control list and then create a new policy-based routing table, the old policy-based routing table might still be active instead of the new table, as shown by the netstat -rn command.Build 089 a03 and later fixes this problem by preventing you from deleting a policy-based routing table that is used by an access control list.



PBR Used with NAT <PR 79022>

With previous builds of IPSO 4.2, policy-based routing might not work correctly for ICMP traffic when a static NAT policy is configured. For example, if you configure an access control list to use a policy-based routing table that routes traffic through a specific gateway and then install a policy that NATs the gateway, ICMP traffic might not follow the policy-based route.Build 089 a03 and later fixes this issue.

Fix for IP225x ADP Issue with Two-Port GigE NICs <PR 80243>

An ADP services module in an IP2250 or IP2255 platform running a previous build of IPSO 4.2 can panic or fail to boot if there are two two-port Gigabit Ethernet NICs installed in the platform. This problem does not occur with any other configuration of NICs. (For example, it does not occur if only one two-port Gigabit Ethernet NIC is installed in the platform.)Build 089 a03 and later fixes this problem.

Fix for Packet Drops on GigE Interfaces <PR 79543>

Systems running previous builds of IPSO 4.2 might drop packets as they ingress or egress an Gigabit Ethernet interface if the interface receives TCP and UDP traffic simultaneously and Auto-Expiry is enabled. (Auto-Expiry is an option on the Advanced System Tuning page. It is enabled by default and improves performance by allowing IPSO to terminate certain connections.) This problem can occur regardless of the overall load on the interface or system.Build 089 a03 and later fixes this problem.



Fix for Incorrect Syslog Interface on Flash-Based Platforms <PR 79522>

On a flash-based platform running a previous build of IPSO 4.2, syslog traffic might bind to an incorrect interface after the platform is rebooted. To correct this problem, you must stop and restart the syslog server.Build 089 a03 and later fixes this issue. After a reboot, syslog traffic binds to the correct interface.

Fix for Link Redundancy Group Containing Link Aggregation Interface <PR 80451>

If you create a link redundancy group that contains a link aggregation interface with a previous builds of IPSO 4.2, the MAC address of the link redundancy group becomes 0:0:0:0:0:0 after the platform is rebooted.Build 089 a03 and later fixes this issue. When you reboot the platform, IPSO maintains the correct MAC address for the link redundancy group.

Fix for Panic Caused by Memory Reports <PRs 76052,

77253>

Systems running previous builds of IPSO 4.2 can panic and restart in circumstances in which they are regularly required to report memory statistics. This can occur, for example, if you regularly run a script that executes vmstat or if you display the Voyager CPU and Memory Utilization page for long periods of time. If this panic occurs, you see the message panic: vm_sysctl in the resulting core file.Build 089 a03 and later fixes this problem.



Fixes for Rare Panics <PRs 71392, 79194, 80039>

Build 089 a03 and later fixes the following problems:Builds 038 and later of IPSO 4.2 might panic when a user process makes a pipe () system call when it has 63 open files. Systems running previous builds of IPSO 4.2 can experience a rare panic that produces an error message similar to the following in the resulting core file:0x903b6124 in vm_map_delete

Systems running previous builds of IPSO 4.2 can also experience a rare crash related to a problem with the function fill_eproc().

Fix for Time Change Problem <PR 31760>

With the earlier builds of IPSO 4.2, rebooting an appliance can sometimes cause the system time and date to be incorrect. If this occurs, rebooting the system a second time corrects the problem. Build 089 a03 and later fixes this issue. With this build, reboots do not cause the time and date to be incorrect.

Fix for IP260/IP265 Temperature Sensing Issue <PRs

57833, 70990>

IP260 and IP265 platforms running builds of IPSO 4.2 previous to Build 078 can have a problem that causes packets to occasionally experience latency of approximately 300 milliseconds. This delay is caused by code related to system temperature sensing and might be noticeable by time sensitive programs such as VOIP applications. Builds 078, 081a01, 081a03, 084, and 088 fix this issue, but as a result of the fix you might see invalid system temperature error log messages.Build 089a03 and later includes a Delay Tuning option that allows you to choose whether you want the system to suppress the invalid temperature error messages:



When the option is enabled (the default), the system temperature is read from sensors after 280 milliseconds delay. The result is that traffic being forwarded may experience packet latency of approximately 300 milliseconds, but the system will not log invalid temperature messages.When the option is disabled, the packet latency of approximately 300 milliseconds is eliminated, but you might see invalid system temperature error messages.

The Delay Tuning option appears on the Advanced System Tuning page for IP260 and IP265 platforms (click Configuration > Advanced System Tuning). This option does not appear for other platforms.

Fix for Automatic Transfer of Archive Files <PR 77416>

The IPSO backup and restore feature includes the capability of automatically transferring backup archive files to a specified remote server every hour.With previous builds of IPSO 4.2, the automatic transfer of backup files can silently stop working under some circumstances. Build 089 a03 and later fixes this issue.

Fix for Adding Loopback Interface with the CLI <PR

78343>

If you use the IPSO CLI to create a new logical loopback interface with a previous build of IPSO 4.2, the interface is not automatically activated (as it is when you use Network Voyager to create the interface).Build 089 a03 and later fixes this issue. When you create a logical loopback interface with the CLI, it is automatically activated.

Fix for Group for Daemon User <PR 80410>

With previous builds of IPSO 4.2, the daemon user, which is the owner of many system processes, belongs to a nonexistent group with GID 31.



Because auditing software might flag this as an issue, the daemon user’s group membership has been changed. With Build 089 a03 and later, the daemon user now belongs to the daemon group, GID 1.

Fix for SNMPv3 Security Vulnerability <PR 78753>

If you use SNMP Version 3 on a Check Point network security platform running a previous build of IPSO 4.2, the system is vulnerable to the issue identified at http://www.kb.cert.org/vuls/id/878044.Build 088 and later fixes this vulnerability.

Fixes for High-Availability FeaturesThis section describes the fixes in this build related to IPSO’s high-availability features—the Virtual Router Redundancy Protocol (VRRP) and IP clustering in previous builds of IPSO 4.2.

Fix for VRRP Preempt Mode Issue <PRs 74027, 78737>

Check Point’s implementation of monitored-circuit VRRP allows you to constrain the number of VRRP transitions (changes of master) by disabling the Preempt mode option. The effects of enabling or disabling this option are summarized below:

Preempt mode enabled (the default setting): If the original master fails, a backup system becomes the acting master (a failover occurs). When the original master returns to service, it becomes the master again (a failback occurs).Preempt mode disabled: If the original master fails, a backup system becomes the acting master. When the original master returns to service, it does not becomes the master again (a failback does not occur).


http://www.kb.cert.org/vuls/id/878044


Systems running previous builds of IPSO 4.2 can behave incorrectly if Preempt mode is disabled and the following scenario occurs:1. A VRRP-enabled non-ADP Gigabit Ethernet interface on the original

master fails, which causes a failover.2. The Gigabit Ethernet interface later recovers and the original master

returns to service. In this situation, IPSO might incorrectly configure VRRP so that mastership is shared between the virtual routers running on the original master and acting master, which causes an interruption in network service.This problem occurs only with Gigabit Ethernet interfaces that are not part of an ADP services module and is fixed in Build 088 and later.

NoteSee “Using VRRP Preempt Mode and Auto-deactivation” on page 186 for more information about using these options.

Fix for VRRP Failback <PR 59226>

If you use VRRP with a previous build of IPSO 4.2 and enable the cold start delay option, connections might be dropped if a failback occurs (that is, if a node that was previously the VRRP master becomes the master again). If the cold start delay threshold is reached before the firewalls in the VRRP group have completely synchronized, any unsynchronized connections are dropped when the original master becomes the master again.Build 088 and later includes a fix that reduces the likelihood of this problem occurring. You can also work around the issue by increasing the cold start delay value.

Fix for Cluster Hash Options <PR 61491>

If you use IP clustering and do not enable a firewall, you can configure the manner in which IPSO balances traffic among cluster nodes. If you want to force connections to be symmetric—that is, if you want to ensure that traffic



for a given connection (both directions) is handled by a specific node, you can use the NAT-INT and NAT-EXT hash options. If you use these hash options with a previous build of IPSO 4.2, the cluster nodes drop packets if both of the following conditions apply to the traffic:

There are multiple possible next hops to the destination (for example, there are two default gateways, each of which is valid for the traffic).Each of the possible next hops (multipath next hops) have the same priority.

This issue is resolved in Build 088 and later.

NoteThe NAT-INT and NAT-EXT options are not available if a firewall is enabled.

Fixes for ADP Issues Certain Check Point platforms running a previous build of IPSO 4.2 can panic and restart if an Accelerated Data Path (ADP) services module is installed and both of the following conditions apply:

An ADP interface receives a fragmented ICMP error packet.Delayed Notification is enabled for the connection that delivers the fragmented packet.

Delayed Notification is enabled by default and improves performance by reducing the amount of required communication between IPSO and the firewall and reducing the amount of synchronization between the members of IP clusters or VRRP groups, thereby reducing overhead processing. It is particularly beneficial when a system processes many short-lived connections. (To disable Delayed Notification as a workaround, access Configuration > Advanced System Tuning in Network Voyager.) Build 088 and later fixes this problem. <PR 77785>



Build 088 and later also fixes a hang that can happen when the system does not properly handle an error message sent by an ADP subsystem. <PR 77659>

These problems do not occur on IP2250 and IP2255 platforms. They can occur on any other platform with an ADP services module installed.

Fix for IP225x ADP Issue <PR 73980>

An ADP services module in an IP2250 or IP2255 platform running a previous build of IPSO 4.2 can panic without causing the system to panic and restart. If an affected ADP interface is a VRRP master when this occurs, there are two possible results:

VRRP failover might not occur, which causes an interruption in service. If a VRRP failover does occur, there is no interruption in service but you no longer have a functional high-availability configuration because the system that experienced the ADP panic does not reboot. Its ADP interfaces remain inactive and the system is not available to become the VRRP master again if the acting master also fails.

Build 088 and later fixes this problem. If an ADP module fails on a platform running this build, the system reboots and reactivates the ADP interfaces.

Fix for SMF NIC Installation <PR 79049>

Previous builds of IPSO 4.2 incorrectly identify single mode fiber optic interfaces (1000Base-LX) if the NIC is installed when you perform either of the following actions:

You start the platform for the first time.You execute the newsystem shell command.

The system incorrectly asks you to choose 10 mbps or 100 mbps as the speed for the interfaces. If you do not choose either of these speeds the system correctly configures the interface speed. If you do choose an incorrect speed, the system overrides your choice and also correctly configures the interface speed.



Build 088 and later fixes this issue. The system correctly identifies single mode fiber optic interfaces during the installation process.

Fix for 10 GigE Interface Not Reactivating <PR 53163>

If you connect a 10 Gigabit Ethernet interface on a Check Point platform running a previous build of IPSO 4.2 to a Cisco switch and deactivate and reactivate the connected interface on the switch using Cisco commands, the corresponding interface on the Check Point system might not be reactivated properly. You can work around this problem by entering the commands shutdown and no shutdown again on the Cisco system. Build 088 and later fixes this problem.

Fix for Eight Port NICs in IP225x <PR 78948>

In IP2250 and IP2255 platforms, NIC slots 1 and 3 are connected to each other by an Accelerated Data Path (ADP) subsystem, and NIC slots 2 and 4 are connected by another ADP subsystem. If you install two eight port 10/100Base-T Ethernet NICs in NIC slots 1 and 3 or 2 and 4 of a platform running a previous build of IPSO 4.2, the ADP subsystem that connects those NIC slots crashes.Build 088 and later fixes this problem.

Fix for Rare IP225x Panic <PR 73979>

IP2250 or IP2255 systems running a previous build of IPSO 4.2 can experience a rare panic that produces an error message similar to the following:#6 0x902d99a1 in host_msg_iterate

Build 088 and later fixes this problem.



Fix for Rare ipsrd Crash <PR 77675>

Build 088 and later fixes a rare problem in which the IPSO routing daemon (ipsrd) crashes and restarts because of high CPU utilization.

Fix for SecureXL and UDP Encapsulation <PRs 77836,

79050>

Certain Check Point platforms running IPSO 4.2 Build 081 and later do not forward encrypted traffic if all of the following conditions apply:

A hardware encryption accelerator is installed in the platform.SecureXL is enabled.UDP encapsulation is enabled. (Encapsulated UDP is typically used to route IPSec traffic through a NAT gateway. For example, Check Point’s Remote Access VPN can use UDP encapsulation.)

This problem occurs only on IP560, IP690, IP1220, IP1260, and IP2450 platforms and is fixed in Build 088 and later.

NoteThe problem does not occur on any platform running a build of IPSO 4.2 previous to Build 081.

Fix for SecuRemote/SecureClient Connections <PR

75401>

If you have a SecuRemote or SecureClient connection to a gateway running a previous build of IPSO 4.2, the connection might be dropped occasionally because of a problem that can occur when the host and gateway renegotiate the connection. Build 088 and later fixes this problem.



Supports IP150IPSO 4.2 Build 084 and later supports the Check Point IP150, a multipurpose 1 RU disk-based security platform that provides a powerful yet cost-effective firewall/VPN/UTM solution. The IP150 is ideal for small businesses and extended sites that require robust performance and also want simple remote central management and high reliability at a low cost. The platform can deliver 550 Mbps large packet firewall performance through four ports of 10/100/1000 Base-Tx Ethernet.

Enhancement for Alternate DNS Server OptionIPSO allows you to configure as many as three DNS servers that the system can check to resolve host names. For example, if you configure two servers and the IPSO system is unable to reach the primary DNS server because of a connectivity issue, it will query the secondary server. However, if a DNS lookup fails because the IPSO system querys for a domain that does not exist (not because of a connectivity problem), IPSO does not repeat the query with the secondary server.Build 084 and later includes an enhancement that you can use to force IPSO to query the secondary or tertiary DNS server if a lookup fails for this reason (that is, if the response is a “non-existent domain” error.)You can enable this option on the Network Voyager DNS Configuration page. You can also use the following IPSO CLI commands:

set dns alternate <on | off>

show dns alternate



Fix for FTP Problem <PR 71395>

With previous builds of IPSO 4.2, a problem occurs in the following circumstance:1. You retrieve a package using nonanonymous FTP (you use a user name

and password).2. You reboot the platform.3. You attempt to retrieve another package using nonanonymous FTP.

When you attempt to retrieve the package after the reboot, IPSO incorrectly uses anonymous FTP even though you provided a user name and password. The system displays the following error message:Retrieving directory: error 74

Error in supplied information

(Please make sure FTP site, directory,

user and password are correct.

Or try using anonymous ftp)

This problem occurs because IPSO improperly stores the FTP user name and password in the current configuration file (/config/active). Note that the stored user name and password is copied to other files under the following circumstances:

If you use the Configuration Sets feature to make a copy of the configuration file.If you boot another IPSO version or build, any copies of the configuration file are copied to /config/db/filename_previous-ipso-version).If you use the Backup and Restore feature to create a backup file while an FTP user name and password are stored, they are saved in the backup file.

Build 084 and later fixes this problem. After installing this build, you must also empty your browser cache to prevent the problem from occurring again.



Fix for Disk Mirroring <PR 66843>

When you enable disk mirroring, the system uses the primary drive as the active drive and copies its contents to the mirror drive for backup purposes. If you enable disk mirroring on a system running a previous build of IPSO 4.2, the system might hang if a drive in the mirror set fails even though the other drive is functioning properly.Build 084 and later fixes this problem.

Fix for Disk Mirror Error Message <PR 58524>

When you boot previous builds of IPSO 4.2 on an IP350 or IP380, the system displays an invalid error message related to disk mirroring, which these platforms do not support. Depending on which earlier build is running, the system displays one of the following messages:

mirror driver direct access error 22

VRRPb [LOG_CRIT] monitord: Disk Drive 0 failure (Mirroring driver DIOCDRIVEINFO ioctl error)

These messages are harmless and do not appear when you boot an IP350 or IP380 with Build 084 and later.

Fix for IP225x ADP Failure <PRs 73327>

An Accelerated Data Path (ADP) services module in an IP2250 or IP2255 platform running IPSO 4.2 Build 051 and later can fail without notifying the IPSO kernel and without disabling the ADP interfaces. Network Voyager and the IPSO CLI report these interfaces as active. Traffic will still be sent to these interfaces but will not be forwarded by the ADP module. If VRRP is enabled on affected ADP interface when this occurs, a VRRP failover does not occur, which causes a service outage.



NoteThis problem is described as an issue with ADP synchronization in a warning message on the download page for IPSO 4.2 Build 078 on the Check Point customer support site. That message indicates that the issue will be fixed in IPSO 4.2 MR3. MR3 is the Check Point internal designation for Build 081 a03.

This problem does not occur with builds of IPSO 4.2 earlier than Build 051 and is fixed in Build 081 a03 and later. If an ADP subsystem fails on a platform running this build, the system reboots. In this situation VRRP fails over properly and there is no interruption in service.

Fix for Crash Related to SecureXL and UDP Encapsulation <PRs 59921, 72977>

A system running a previous build of IPSO 4.2 with SecureXL enabled might crash and reboot if it accelerates an encapsulated UDP connection. (Encapsulated UDP is typically used to route IPSec traffic through a NAT gateway.)Build 081 a03 and later fixes this issue.

Fix for Rare SecureXL-Related Crash <PR 64218>

Systems running a previous build of IPSO 4.2 with SecureXL enabled can experience a rare crash related to a page fault. Build 081 a03 and later fixes this issue.

Support for ADP Modules with IP690IPSO 4.2 Build 081 a01 and later supports the release of Check Point Accelerated Data Path (ADP) services modules for Check Point IP690



network security platform. The ADP modules are optional add-ons for this platform. Check Point ADP modules accelerate firewall and VPN throughput by allowing the system to offload packet processing from the CPU to network processors on the modules. Each module includes two four-port NICs for a total of eight ports. You can install the following hot swappable small form-factor pluggable (SFP) transceivers in the ports:

1000Base-LX Transceiver Module1000Base-SX Transceiver Module1000Base-T Transceiver Module

See “Issues with ADP Cards and Link Redundancy” on page 217 for information about a limitation related to using ADP interfaces in a link redundancy group.

Supports ADP Module with IP690IPSO 4.2 Build 081 supports the use of an Accelerated Data Path (ADP) module with the Check Point IP690 network security platform. The ADP module is an optional add-on for this platform.

NoteUpgrade to IPSO 4.2 Build 081 before you install the ADP module. Previous builds of IPSO 4.2 do not recognize this module when installed in an IP690.

Check Point ADP modules accelerate firewall and VPN throughput by allowing the system to offload packet processing from the CPU to network processors on the cards. Each card includes two four-port NICs for a total of eight ports. You can install the following hot swappable small form-factor pluggable (SFP) transceivers in the ports:

1000Base-LX Transceiver Module1000Base-SX Transceiver Module



1000Base-T Transceiver Module

Enhancement for Identifying Disk-Based Platforms <PR 70490>

With previous builds of IPSO 4.2, Network Voyager identifies flash-based platforms by displaying “Flash Based” after the model number on the Voyager home page. If you enter the CLI command show asset software on a flash-based platform, the CLI indicates that the system is flash based. If you have a disk-based platform, Voyager and the CLI do not explicitly identify it as such.With Build 081 a01 and later, the Voyager home page displays “Disk Based” after the model number and the output of the show asset software command explicitly identifies disk-based platforms.

Fix for SSL-Related Security Vulnerability <PR 71013>

Systems running previous builds of IPSO 4.2 are vulnerable to the SSL-related security vulnerability identified at http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5135.Build 081 a01 and later includes a fix for this vulnerability.

Fix for ipsrd Crash <PR 66539>

On systems running previous builds of IPSO 4.2, the IPSO routing daemon (ipsrd) can crash if PIM Sparse-Mode is enabled and all of the following conditions apply:

A large number of multicast senders (roughly more than 150) send traffic to at least 10 multicast groups.Receivers on a LAN subscribe to these groups.All of the receivers leave and rejoin all the multicast groups that they subscribe to. (For example, this might occur when laptop users disconnect and reconnect to a LAN.)


http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5135.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5135.


A Check Point platform is configured as the multicast designated router for the receivers or a Check Point platform is upstream from the designated router.

If this scenario occurs, ipsrd can crash on the designated router or the upstream Check Point platform. When the IPSO routing daemon attempts to stop on a system running a previous build of IPSO 4.1, it crashes and produces a core dump file. For example, this occurs if you power down or reboot the system. When ipsrd restarts it functions normally. <PRs 65918, 67739>

Build 081 a01 and later fixes this problem.

Fix for Boot Issue with IPSO 4.2 Build 051 <PR 67063>

A problem can occur with disk-based Check Point network security platforms if you do the following:1. You install IPSO 4.2 Build 051 (a02, a04, or HFA02) on a disk-based

platform and upgrade the boot manager as part of the process.2. You later install another version of IPSO using any installation method.After you perform the second IPSO installation, boot times might be very long—as much as ten minutes on platforms with slower processors.This problem does not affect flash-based platforms (including hybrid platforms). It is partially fixed in Build 069 and is completely fixed in Build 081 a01 and later. (With Build 069 boot times are substantially reduced, and they are further reduced with Build 081 a01 and later.)



To prevent the problem, you must install the boot manager for Build 081 a01 and then perform of fresh installation of Build 081 a01. For example, follow these steps:1. Download the IPSO 081 a01 image and boot manager (nkipflash-4.2.bin)

from download page for IPSO 4.2 Build 081 a01 on the Check Point customer support Web site at http://support.checkpoint.com.

2. Enter: upgrade_bootmgr wd0 nkipflash-4.2.bin

at the IPSO command shell.3. When the system indicates that the boot manager upgrade is complete,

enter: reboot

4. Perform a fresh installation of IPSO Build 081 a01.

Fix for Issue with NAT and Cluster IP Address <PR

69063>

If you use IP clustering with a previous build of IPSO 4.2 and also use NAT, a problem can occur if both of the following are true:

You use a cluster IP address as the address to hide behind.You set the cluster hash options to force connections to be symmetric (one node handles all the traffic for a connection).

In this situation, previous builds of IPSO 4.2 do not force connections to be symmetric. This can prevent connections from being established in situations in which one node does not receive all of the TCP handshake packets, such as the following:1. Node 1 receives a syn packet.2. Node 2 receives the corresponding syn ack packet.

3. If the firewalls have not synchronized connection information for this connection when node 2 receives the syn ack, it drops the packet because


http://support.checkpoint.com

http://checkpoint.nokia.com

http://checkpoint.nokia.com


it did not receive the appropriate syn packet. Connection establishment is not completed.

This problem occurs only if you use a cluster IP address to hide behind. It does not occur with other addresses and is fixed in Build 081 a01 and later.

Fix for VPN-Related Fragmentation Issue <PR 69248>

Certain systems running a previous build of IPSO 4.2 drop fragmented packets if all of the following conditions apply:

A fragmented packet is smaller than 28 bytes (including header and data).The packet is supposed to be encrypted and forwarded over a VPN link.A hardware encryption accelerator is installed in the platform.

This problem occurs only on IP560, IP690, IP1220, IP1260, and IP2450 platforms and is fixed in Build 081 a01 and later.

Fix for Issue with Build 051 and Specific NICs <PR

71317>

If you upgrade a Check Point security platform to IPSO 4.2 Build 051 (a02, a04, or HFA02), the platform might not boot after the upgrade if certain Ethernet or Gigabit Ethernet NICs are installed. The problem can occur with any of the following NICs:

Two Port Gigabit Ethernet MMF PMC, NIF4402xxxFour port 10/100 Mbps Ethernet PMC, NIF4404xxxFour port 10/100/1000 BaseTx, copper, NIF4426xxx

In some cases the platform boots properly after the upgrade, but some or all of the NICs do not work. If you purchase an IP2450 with Build 051 installed and any of these NICs are installed, the NICs might not work properlyBuild 081 a01 and later fixes these problems.



Fix for Disk Mirror Issue with IP12xx <PR 69998>

If you hot swap a second hard disk into an IP1220 or IP1260 platform running a previous build of IPSO 4.2, you cannot create a mirror disk set until you reboot the platform. Build 081 a01 and later fixes this problem—if you hot swap a second disk into an IP12xx platform running this build, you can create a mirror disk set immediately without rebooting the platform.

Fix for Compact Flash Corruption after Panic on Flash-Based Systems <PR 61949>

The compact flash memory in flash-based platforms running previous builds of IPSO 4.2 can be corrupted as a result of a system panic. Build 081 a01 and later fixes this problem—with this build, a system panic does not cause the compact flash to be corrupted.

Fix for Misidentified PCMCIA Slots <PR 70120>

If you insert a PCMCIA card into a system running a previous build of IPSO 4.2, the system might misidentify the slot that the card is installed in. For example, if you insert the card in slot 1, Network Voyager, the IPSO CLI, and the boot manager might indicate that the card is installed in slot 2. This problem does not affect the functionality of the card and is fixed in Build 081 a01 and later.

Supports IP1280IPSO 4.2 Build 081 and later supports the release of the Check Point IP1280, a two rack unit network security appliance that delivers maximum business continuity through features such as redundant dual and hot-swappable AC or DC power supplies, hot-swappable fan trays, and optional redundant hard disk drives with RAID level 1. To provide optimal reliability, Check Point offers the IP1280 in a flash-based configuration, and it is available in a disk-



based configuration as well. The IP1280 is fully compatible with existing Check Point-supported PMC interface cards, which provides investment protection by enabling you to reuse the equipment you already have. The new platform also includes a built-in hardware encryption accelerator for VPN connections.

Enhancement for Static Multicast RoutesWhen Protocol Independent Multicast (PIM) is enabled, PIM expects packets to arrive on the reverse-path forwarding (RPF) interface, that is, the interface used to reach the source of the multicast data. PIM also checks the RPF to learn which interface it should use to send join/prune messages. With previous builds of IPSO 4.2, the RPF interface is always identified by the unicast routing table. IPSO 4.2 Build 078 and later includes static multicast routes, which you can use to provide an alternative route table to use for the RPF check. If both a static multicast route and a unicast route are available for a specific destination, PIM uses the static multicast route. Static multicast routes allow PIM to be independent of unicast routing and let you deploy topologies in which multicast and unicast traffic flow over different paths. For instance, if you want to balance your traffic load by separating the path used by HTTP traffic from the path used by streaming stock quotes, you could configure a static multicast route to the source network that specifies a next hop gateway address that is different from the next hop address (for the same source) in the unicast routing table.To configure static multicast routes using Network Voyager, click Configuration > Routing > Static Multicast Routes in the navigation tree.

NoteIf Static Multicast Routes does not appear in the navigation tree after you install Build 078 and later, refresh your browser window.



To configure static multicast routes using the IPSO CLI, use the following commands:set static-mroute <sender_IP_address/mask | default>

nexthop gateway address gateway_address <on | off | priority <1-8>>

logical logical_interface priority <on | off | priority <1-8>>

off

show static-mroute

Table 3 Static Multicast Route CLI Arguments

Parameters Description

sender_IP_address/mask Specifies the address and network mask of the multicast sender.

default Specifies a default gateway to use for RPF lookups.

gateway_address Specifies the address of the gateway router.

logical_interface Specifies the name of the logical interface that connects to the gateway router.

priority <1-8> Specifies the order in which the next hops are selected when there are multiple next hops for the same destination. The next hop with the lowest priority value is used. If the interface for this next hop fails, IPSO uses the next hop with the next lowest value.



This feature is supported in combination with NGX R62.

Enhancement for Redundant Switches <PR 65263>

IPSO 4.2 Build 029 introduced link redundancy, which you can use to configure redundant Ethernet interfaces for resiliency purposes. For example, if you create a link redundancy group that includes two physical interfaces and the active interface fails, the second interface takes over and there is no interruption in service.

NoteThere is no load balancing within a link redundancy group—only one of the interfaces in a group is active at a given time.

With previous builds of IPSO 4.2, all the interfaces in a link redundancy group must connect to the same device at the other end of the link. You cannot configure a single redundancy group across multiple switches. IPSO 4.2 Build 078 and later enhances this feature so that the members of a redundancy group can connect to multiple switches. By using a Check Point high-availability solution and connecting redundant interfaces to redundant switches, you can create highly resilient network

on Enables the specified multicast static route.

off Disables the specified multicast static route.

Table 3 Static Multicast Route CLI Arguments




configurations. For example, if you use VRRP, you can set up redundant switches by using a configuration such as the following:1. Using internal interfaces, create a link redundancy group on each system

(platforms A and B).2. On platform A:

a. Connect the primary redundant interface to redundant switch A.b. Connect the secondary redundant interface to redundant switch B.

3. On platform B:a. Connect the primary redundant interface to redundant switch B.b. Connect the secondary redundant interface to redundant switch A.

4. If there are VLANs configured on the switches, put all the switch ports you used in steps 2 and 3 in the same VLAN.

5. If necessary, connect the switches with a trunk link (to support VLANs, for example).

6. Repeat this procedure using external interfaces on your Check Point platforms and additional switches.

By deploying a configuration such as this you can eliminate a single switch as a single point of failure and extend your high availability configuration on both sides of your firewall.

Enhancement for MSS for DVMRP and GRE Tunnels <PR 58611>

Build 078 and later includes a feature that allows you to set the Maximum Segment Size (MSS) as part of configuring a DVMRP or GRE tunnel. You can use this feature to tune TCP performance for connections that are terminated or proxied on the appliance.In Network Voyager, use the MSS Clamping field in the Logical Interface configuration page for a tunnel to configure the MSS. The value set in this field will be used by TCP when establishing a connection.



Enhancement for SSL Support <PR 63970>

To ensure more secure connections to Network Voyager, Build 078 and later does not accept SSL connections using SSLv2 ciphers. You must enable SSLv3 in your browser to connect to Network Voyager.

Enhancement for Anti-virus and URL Filtering on VLANs <PR 58499>

IPSO 4.2 Build 051 and later, in combination with Check Point’s NGX R65, supports anti-virus and URL filtering, but these features are not supported with virtual local area networks (VLANs). With Build 078 and later and NGX R65, you can use anti-virus and URL filtering on VLANs.

Enhancement for Venezuela Time Zone Change <PR 67013>

Build 078 and later of IPSO 4.2 supports the Venezuela time zone change that went into effect on December 9, 2007. The Venezuela time zone is now GMT -4:30 rather than the previous GMT -4:00.

Fixes for High-Availability FeaturesThis section describes the fixes in this build related to IPSO’s high-availability features—the Virtual Router Redundancy Protocol (VRRP) and IP clustering in previous builds of IPSO 4.2.

Fix for VRRP Transition Issue <PR 57142>

If you use VRRP on systems running a previous build of IPSO 4.2, a problem can occur if a system that is configured to be the master returns to service after a link failure. In certain circumstances, there can be a delay for as long as



several seconds during which neither system acts as master, which might cause a very brief interruption in service.Build 078 and later fixes this problem.

Fix for Dual VRRP Masters on IP225x <PR 59760>

When running previous builds of IPSO 4.2, both IP225x appliances in a VRRP pair running PIM Dense mode can become master a few minutes after you enable SecureXL on the appliances. This might happen if you have multiple VLANs configured on a eight-port Ethernet NIC.This issue is resolved in Build 078 and later.

Fix for VRRP Backup Address Issue <PR 63719>

If you use the Simplified VRRP Configuration, you enter backup addresses (virtual addresses) that IPSO automatically associates with the interfaces that have addresses on the same networks. On a system running a previous build of IPSO 4.2, a problem occurs if you add an invalid backup address—that is, an address that does not belong to any of the networks that are configured on the interfaces. In this circumstance, IPSO correctly rejects the invalid backup address but does not display an error message. If you subsequently attempt to add a valid backup address, IPSO appears to create the address, but the address is not functional.This issue is resolved in Build 078 and later.

Fix for SNMP OID Sent with VRRP Trap <PR 68917>

If you enable SNMP and VRRP and a VRRP failover occurs, the new master sends a trap to indicate that the transition has occurred. On a system running a previous build of IPSO 4.2, the trap includes an incorrect object identifier (OID) for the VRRP interface.Build 078 and later fixes this problem.



Fix for Cluster ARP Issue <PR 65989>

If you use IP clustering with a multicast mode enabled on systems running a previous build of IPSO 4.2, a problem can occur when the cluster sends ARP requests. The ARP requests include the cluster IP address (a unicast address) as the source address and the cluster MAC address (a multicast address) as the source MAC address. If an adjacent router does not accept this combination of addresses in ARP requests, it does not reply to the request and the cluster does not learn its MAC address, which prevents the cluster from sending traffic to that router.With IPSO 4.2 Build 078 and later, IP clusters send the IP address of an interface on the master node as the source IP address in ARP requests and send the MAC address for that interface (a unicast address) as the source MAC address. (IPSO 4.1 and earlier also send ARP requests in this format.) Adjacent routers should always reply to ARP requests with these source addresses.When sending ARP replies (whether they are gratuitous replies sent to advertise the cluster MAC or replies sent in response to ARP requests), IP clusters always send the cluster IP and cluster MAC as the source addresses.

Routing-Related FixesIPSO 4.2 Build 078 and later includes the routing-related fixes described in this section.

Fixes for ipsrd Crashes Build 077 fixes a variety of issues that can cause the IPSO routing daemon (ipsrd) to crash.If you enable VRRP and RIP on a system running a previous build of IPSO 4.2 and later configure a static route in which the next hop type is reject or black hole, ipsrd crashes a short time later and the system stops forwarding traffic. If a VRRP failover occurs and the new master also has a reject or black



hole static route, the problem also occurs on the new master. You must reboot the systems and remove the static route to work around the issue. <PR 67690>

The IPSO routing daemon can also crash on a system running a previous build of IPSO 4.2 if you enable PIM Sparse-Mode and the system acts as a turnaround router, which means that it is downstream from the RP but the RPF interface to a multicast source and the RPF interface towards the RP are different interfaces. In this circumstance, if the Check Point system receives an (S,G) RPT join message from a downstream router, ipsrd crashes. <PR 67240>

If you use PIM with a system running a previous build of IPSO 4.2, a problem can occur if you have the following configuration:

There is a local receiver on the interface towards a multicast source, and this is not the interface towards the rendezvous point (RP). There is also a route to the source on the interface toward the RP.

In this situation, ipsrd crashes if the original route towards the source is lost. <PR 57854>

A PIM Dense-Mode related ipsrd crash can occur if a unicast route is lost while multicast traffic is flowing over it. <PR 67838>

When the IPSO routing daemon attempts to stop on a system running a previous build of IPSO 4.2, it crashes and produces a core dump file. For example, this occurs if you power down or reboot the system. When ipsrd restarts it functions normally. <PRs 65918, 67739>

Build 078 and later fixes these problems.

Fix for Equal-Cost Routing and Wire Mode <PR 60008>

If you use OSPF equal-cost routing in combination with Check Point wire mode on a system running a previous builds of IPSO 4.2, packets can be dropped.Build 078 and later fixes this issue when you use equal-cost routing to balance traffic between routers on the same network. The problem still exists if you use equal-cost routing with routers on different networks.



Fixes for Policy Based Routing <PRs 63847, 69238>

With IPSO 4.2 Build 069 and later, you can exert detailed control over traffic forwarding by using policy based routing (PBR). When you use PBR, you create routing tables of static routes and you direct traffic to the appropriate tables by using an access control list (ACL). Using an ACL in this way lets you direct traffic flow by filtering on one or more of the following:

Source addressSource mask lengthDestination addressDestination mask lengthSource portDestination portProtocol type

With Build 069, the following problems occur with PBR when the firewall is enabled:

PBR does not work if you enable SecureXL or IPSO flows.PBR does not work if you disable SecureXL but configure an ACL with the following settings:

The source address is 0.0.0.0/0.The destination address is 0.0.0.0/0.The source and destination ports are configured with nonzero values.The protocol type is TCP or UDP.

In both of these situations, IPSO does not apply the policy based routing and routes traffic using the standard routing.Build 078 and later fixes these issues.

Fix for Response to IGMP Queries <PR 59821>

If you have local IGMP groups configured with previous builds of IPSO 4.2, the system does not respond to IGMP queries with IGMP group-specific reports, but sends the reports at random intervals, often minutes apart. This



can cause the router connected to the Check Point appliance to time out and terminate IGMP group membership.Build 078 and later fixes this issue. When local IGMP groups are configured, the appliance now responds to IGMP queries with group-specific reports.

Fix for EBGP Routes Issue <PRs 70115, 70340>

If you use EBGP on a system running a previous build of IPSO 4.2 and the system is rebooted for any reason, it does not redistribute routes to its EBGP peers after the reboot.Build 076 fixes this issue.

Fix for BGP Update Issue <PR 68463>

If a system running a previous build of IPSO 4.2 with BGP enabled advertises an aggregated route to a peer and that route later becomes inactive (because of a link failure, for example), the Check Point system does not withdraw the aggregated route from the peer. If any other routes learned by BGP become inactive, they are correctly withdrawn.Build 078 and later fixes this issue.

Fix for Voyager Issue with PIM and GRE <PR 69092>

If you enable PIM on a system running a previous build of IPSO 4.2 and also configure a GRE tunnel, you cannot configure PIM for the GRE interface using Voyager because the interface is not listed on the PIM configuration page. You can configure PIM on the GRE interface by using the IPSO CLI.Build 078 and later fixes this issue.

Fix for PIM Display Error <PR 68920>

If PIM SSM mode is enabled on a system running a previous build of IPSO 4.2, Network Voyager (PIM Monitor page) and the IPSO CLI (output of show pim joins) incorrectly indicate that PIM is running in sparse mode. This



display error has no effect on any functionality and is fixed in Build 078 and later.

Fixes for Issues Specific to IP225x PlatformsThis section explains fixes for issues that are specific to the IP2250 and IP2255 network security platforms.

Fix for Memory Leak <PR 60028>

IP2250 and IP2255 platforms running previous builds of IPSO 4.2 can experience a significant memory leak if they support a large number of FTP connections over a period of time. With previous builds of IPSO 4.2, these systems leak a small amount of memory each time an FTP connection is established through the system, and the leaked memory is not reused when the connection is closed. If the cumulative number of FTP connections—that is, the total number of opened and closed connections—reaches into the millions, the amount of leaked memory can cause significant performance degradation.Build 078 and later fixes this issue.

Fix for NAT-Related Crash <PR 57188>

IP2250 and IP2255 platforms running previous builds of IPSO 4.2 can experience an ADP-related crash that is most likely to occur if Hide NAT is enabled on the firewall.Build 078 and later fixes this issue.

Fix for VPN Connection Drops <PR 64019>

SecureClient and SecuRemote connections through a IP2250 or IP2255 platform with a VPN accelerator installed and running a previous build of IPSO 4.2 might be dropped.

Build 078 and later fixes this issue.



Fix for Low-Throughput Latency Issue <PR 68919>

IPSO 4.2 includes an option for IP2250 and IP2255 systems that you can use to configure the latency experienced by packets when the traffic load on the system is light. If you enable this option (which is available on the Advanced System Tuning Voyager page), packet latency is minimized regardless of the traffic load (when measured under certain conditions). When the option is disabled (the default setting), the latency of some packets can be more than expected when the traffic load is very light.On systems running previous builds of 4.2 with this option enabled, a very small number of packets might still experience significant latency when the throughput is low. Build 078 and later substantially reduces the latency experienced by this small number of packets.

NAT-Related FixesA problem can occur if you enable NAT on an IP2250 or IP2255 system running a previous build of IPSO 4.2. In certain circumstances, IPSO incorrectly recalculates TCP header checksums when applying NAT, which causes destination systems to drop the packets. <PR 65013>

When running previous builds of IPSO 4.2 with SecureXL enabled, all Check Point platforms recalculate the TCP checksum incorrectly on fragmented traffic when configured to perform server-side static NAT. The invalid TCP checksums cause the destination to drop the packets. <PR 63339>

Build 078 and later fixes these problems.

Fix for Upgrade Issue <PR 61391>

If you upgrade a Check Point security platform from IPSO 3.9 or earlier to an earlier build of IPSO 4.2, a problem can occur that causes the xpand daemon to crash after the upgrade, which prevents you from seeing any configuration information or configuring the system.




Fix for Panic Caused by Link Aggregation <PR 67714>

Systems running previous builds of IPSO 4.2 might panic under certain circumstances if you enable link aggregation and use layer 4 (L4) for the aggregate transfer policy. (When configured this way, IPSO distributes the outgoing traffic across the physical interfaces using hash values based on the destination TCP or UDP port numbers.)Build 078 and later fixes this problem.

Fix for VPN-Related Issue <PRs 62688, 65913>

Certain systems running a previous build of IPSO 4.2 can experience a performance issue if SecureXL is enabled and an VPN accelerator installed. In some circumstances, these systems periodically stop forwarding encrypted traffic for periods as long as one second. If there is a large number of tunnels when this occurs, it can result in high CPU usage and significantly degrade throughput.This problem can occur only on IP560, IP690, IP1220, and IP1260 platforms and is fixed in Build 078 and later.

Fix for VPN Accelerator Statistics Issue <PR 56021>

Systems running a previous build of IPSO 4.2 with a Check Point VPN accelerator installed do not provide valid performance statistics for the VPN accelerator through Check Point’s SmartView Monitor or when responding to the command fwaccel stats.Build 078 and later fixes this problem with the output of fwaccel stats. If you execute this command on a system running this build you see valid statistics. SmartView Monitor still does not display the correct information.



Fix for Proxy ARP Issue <PR 58737>

If you delete a proxy ARP entry on a system running a previous build of IPSO 4.2 and later create a new entry using the same IP address and a new MAC address, IPSO might continue to use the original MAC address when replying to ARP requests for that IP address.Build 078 and later fixes this problem.

Fix for Repeated Interface Down Messages <PR59311>

Under certain circumstances, if you deactivate a Gigabit Ethernet interface on a system running a previous build of IPSO 4.2, the log message generated by deactivating the interface repeats every few seconds.Build 078 and later fixes this problem.

Fix for User Names <PRs 60154, 62089>

If you configure a local or nonlocal user (for example, a user created on a RADIUS or TACACS+ server) and include a hyphen in the user name, that user cannot successfully use Network Voyager on a system running a previous build of IPSO 4.2. This is also true if you create a nonlocal user with a period in the user name. (The problem with periods applies only to nonlocal users because you cannot create user names with periods for local users.)The IPSO CLI is not affected by this problem, and Build 078 and later fixes it for Network Voyager. User names that include hyphens (local and nonlocal users) and nonlocal user names that contain periods do not cause problems with Network Voyager.

NoteYou still cannot create local user names that include periods.



Fix for IP260/IP265 Latency Issue <PR 57833>

Packets transiting IP260 and IP265 systems running previous builds of IPSO 4.2 occasionally experience latency of approximately 300 milliseconds. This delay is caused by code related to temperature sensing and might be noticeable by time sensitive programs such as VOIP applications.Build 078 and later fixes this issue.

Fix for SNMP ifOutUcastPkts Counter <PRs 49664, 57262,

63488>

With previous builds of IPSO 4.2, the value shown in the ifOutUcastPkts counter of the Interfaces MIB can decrement erroneously. Build 078 and later fixes this problem.

Fix for AUX Serial Port <PR 61397>

On systems running previous builds of IPSO 4.2, the auxiliary serial port (COM2) is sometimes unable to transmit data.Build 078 and later fixes this problem.

Fix for RAID Disk Issue on IP2450 <PR 65463>

If you enable RAID on an IP2450 with one hard disk installed and want to add a second disk to the RAID volume, the second disk must have at least the capacity of the current disk. If RAID is active on an IP2450 running a previous build of IPSO 4.2 and you add a hard disk that has a smaller capacity than the active RAID disk, IPSO correctly does not add the smaller disk to the RAID volume. However, if you press the hot swap button in preparation for removing the smaller disk, the Hot Swap Ready LED on the unit does not illuminate blue, which you should normally wait for before physically



removing a disk. Even though the LED is not blue, you can remove a disk in this state without corrupting data.Build 078 and later changes system behavior when a smaller-capacity disk is added to an IP2450 with RAID enabled:

The Hot Swap Ready LED does illuminate blue if you press the hot swap button on a smaller-capacity drive. If you do not remove the smaller disk, you can mount it as a separate disk (not part of the RAID volume).

Supports Release of ADP Modules IPSO 4.2 Build 069 and later supports the release of Check Point Accelerated Data Path (ADP) modules for Check Point IP560, Check Point IP1220, and Check Point IP1260 platforms. The ADP modules are optional add-ons for these platforms.

NoteUpgrade to IPSO 4.2 Build 069 before you install the ADP modules. Other versions and builds of IPSO do not recognize these modules.

Check Point ADP modules accelerate firewall and VPN throughput by allowing the system to offload packet processing from the CPU to network processors on the modules. Each module includes two four-port NICs for a total of eight ports. You can install the following hot swappable small form-factor pluggable (SFP) transceivers in the ports:

1000Base-LX Transceiver Module1000Base-SX Transceiver Module1000Base-T Transceiver Module

See “Issues with ADP Cards and Link Redundancy” on page 217 for information about a limitation related to using ADP interfaces in a link redundancy group.



Interface Changes When you install these ADP modules, IPSO automatically creates interface names for the ADP interfaces and changes the existing interface names and configuration information, as explained below:

If you install an ADP module in an IP1220 or IP1260, the names and configuration information for all the interfaces previously installed in slots 1 and 2 become invalid.If you install an ADP module in an IP560, the names and configuration information for the interfaces previously installed in slot 2 becomes invalid.The interface names of the interfaces installed in slot 1 of an IP560 do not change.

These changes can affect any features or protocols that use the existing interfaces or their addresses, including the following:

Dynamic routing protocolsMulticast routing protocolsStatic routing configurationVRRPIP clusteringTransparent modeLink aggregationLink redundancyTraffic management/QoS

NoteAfter you install an ADP module, reconfigure any protocols and features that used the removed interfaces to use the ADP interfaces. Reassign IP addresses from the removed interfaces to the ADP interfaces as appropriate.



Configuring IPSO for ADP InterfacesThe following procedure covers the high-level process of installing and configuring an ADP module. For detailed information on this process, see the product documentation.1. Install IPSO 4.2 Build 069 (or later) and boot this build.2. Power the platform down.3. Remove the NICs that you intend to replace.4. Install the ADP module.5. Restart the platform.6. Log into the system using Network Voyager.7. Navigate to the Interface Configuration page.

The removed interfaces are still listed on this page, and you see a blue indicator next to each of them in the Up column.

8. Delete the interface names and configuration information for each interface you removed by performing the remaining steps:

NoteTo delete an interface used by VRRP or IP clustering, you must first disable the feature that uses the interface.

9. Click a physical interface name. Voyager displays the Physical Configuration page for that interface.

10. In the Physical Status area, click the Delete check box.11. Click Apply.12. Click Save.13. Delete the configuration information for another interface by restarting

this procedure at step 7.



14. If appropriate, configure the ADP interfaces to use the IP addresses previously assigned to the removed interfaces.

15. Reconfigure any protocols and features that used the removed interfaces to use the ADP interfaces.If appropriate, reenable VRRP or IP clustering.

Configuring Network Topology with an IP560There are several constraints that are relevant to your network topology after you install an ADP interface module in an IP560 relevant to the interaction of ADP interfaces and non-ADP interfaces. These constraints do not apply to the IP1220 or IP1260 because there are no non-ADP interfaces available for production traffic after you install an ADP interface module in these platforms. (You should not use the built-in 10/100 mbps interfaces for production traffic.)When you install an ADP interface module in an IP560, Check Point recommends that you configure your network so that your platform does not forward traffic between ADP interfaces and non-ADP interfaces even if the non-ADP interfaces are Gigabit Ethernet. Using a configuration of this type can significantly degrade throughput.When you install an ADP interface module in an IP560, the network processor in the module performs all VPN encryption and decryption, even for VPN packets that ingress or egress through non-ADP interfaces. The built-in Check Point encryption accelerator continues to accelerate IKE traffic but does not perform any other processing. If VPN traffic ingresses or egresses through a non-ADP interface, throughput is negatively affected because the packets must transit the IP560 backplane to reach the network processor in the ADP module. Check Point recommends that you configure your VPNs to use only ADP interfaces to avoid this performance loss.

ADP Core Dumps If you install a Check Point ADP module in an IP560, IP1220, or IP1260 platform and the ADP subsystem crashes, it creates an ADP core dump that



the system captures and stores as a compressed file. Check Point can use these files for troubleshooting purposes.If you configure the system to automatically transfer core dumps to an FTP server for storage (recommended for flash-based platforms), ADP core dumps are automatically transferred. Otherwise, ADP core dumps are stored in /var/emhome/admin.To access the Check Point Network Voyager page that you can use to configure the system to automatically transfer core dumps, click Remote Core Dump Server under Configuration > System Configuration in the Voyager Navigation tree. When an the ADP subsystem crashes, the system creates a kernel file and a core file using the following naming scheme:

kaza.perf_g-day-month-date-hh-min-sec-year-u<unit_number>s<slot_number>.Z

kcore-day-month-date-hh-min-sec-year-u<unit_number>s<slot_number>.Z

For example, the following files might be created:kaza.perf_g-Fri-Dec-14-09-45-20-2007-u0s1.Z

kcore-Fri-Dec-14-09-45-20-2007-u0s1.Z

If an ADP subsystem crashes, IPSO subsequently crashes as well. The IPSO core dump is stored locally or transferred to an FTP server according to the settings on the Remote Core Dump Server configuration page.

NoteIf an ADP subsystem in an IP2255 platform crashes, the system does not save a kernel or core dump file.



Fixes for IP Clustering on IP225x <PRs 59713, 59743, 60834,

61054, 61057, 61131, 61394, 61946, 62288, 62841, 62892, 62964, 62965, 62988, 63017, 63113,

63142>

IPSO 4.2 Build 069 and later includes changes that enhance the stability of IP2250 and IP2255 systems running IP clustering in forwarding mode. These changes reduce the likelihood of crashes and other problems occurring on these systems.

NoteCheck Point recommends that you upgrade to IPSO 4.2 Build 069 if you enable IP clustering on IP2250 and IP2255 systems and use forwarding mode.

Enhancement for NAT with Transparent Mode <PR

59274>

When you enable transparent mode on interfaces, they forward traffic like a layer 2 device—they do not need IP addresses. Using transparent mode can help you fit a firewall into a LAN without reconfiguring the network or allow you to maintain an existing IP address provided by your ISP. Previous builds of IPSO 4.2 do not allow you to use network address translation (NAT) with transparent mode interfaces. This constraint is removed with Build 069 and later.

Fixes for Kernel Core Dumps If a Check Point network security platform crashes unexpectedly, it creates a kernel core dump at the time of the crash. This core dump can be used to troubleshoot the cause of the crash. Flash-based platforms can store kernel core dumps on the internal compact flash memory or on an external PCMCIA compact flash memory card.



Some flash-based platforms shipped to customers starting in 2007 cannot store kernel core dumps on the internal compact flash memory because of a problem with the memory. To learn whether your flash-based platform has this issue, enter the following command at the IPSO shell:ipsctl hw:disk:wd:0:model

If the response is hw:disk:wd:0:model = STI Flash 8.0.0

your platform cannot create a core dump on the internal flash if the system crashes. If the STI Flash number in the response is less than 8.0.0, the platform is not affected by this problem. <PRs 59845, 60032, 61765>IPSO 4.2 Build 06x fixes this issue.

Enhancement for IP2255 and IP2450 Core Dumps <PR 60630>

Check Point recommends that you configure flash-based systems to automatically transfer core dumps to an FTP server for storage (instead of storing the dumps in flash memory). With previous builds of IPSO 4.2, the following scenario can occur with an IP2255 or flash-based IP2450 system configured this way:1. The system crashes and creates a core dump.2. The system restarts and starts to FTP the core to an FTP server.3. Before the FTP transfer completes, the system crashes again and creates

another core dump (and retains the first dump).4. The system restarts and transfers the first core to the FTP server.In this situation, the system does not automatically transfer the second core dump to the FTP server. If a third crash occurs after the system transfers the first core to the server, it will transfer the third core but will not transfer the second core, which remains on the internal flash memory. (This situation does not apply to other flash-based platforms because they can store only one kernel core dump.)



IPSO 4.2 Build 069 and later fixes this issue. If the above scenario occurs, the system transfers the second core to the FTP server. With any build of IPSO 4.2, you can learn whether there are any core dumps stored by entering the following command at the IPSO shell prompt:savecore -t

If there are any saved cores, you can transfer them to a remote FTP server, by entering the following command:savecore -r ftp://

username:password@ftp_server_IP_address/directory/

Enter this command twice to transfer two kernel core dumps.After the system transfers a core to a remote server, it deletes the core from the flash memory.

Enhancements for Storing Core Files <PRs 56989, 57336>

IPSO 4.2 Build 069 and later includes enhancements to allow flash-based IP390, IP560, IP1220, and IP1260 systems to save larger kernel core-dump files. If you use IPSO 4.2 Build 069 and later in combination with a supported one gigabyte flash-memory PC card, the system can store kernel core-dump files much larger than those allowed by the swap space allocated for kernel core dumps on the built-in flash memory. (This capability is supported with IP2255 and IP2450 platforms and previous builds of IPSO 4.2.)

Storing Kernel Core DumpsTo configure the system to store kernel core dumps on a PC card, follow this procedure:1. Insert a supported flash-memory PC card into the platform.2. Navigate to the Optional Disk Configuration page in Network Voyager

(System Configuration -> Optional Disk).3. Select Kernel Dump.4. Wait until you see a message indicating that you should reboot the system.



There is a short delay before the message appears.5. When the message appears, click Reboot, Shutdown System. 6. Reboot the system.

WarningWhen you select a flash-memory card as an optional disk, any existing data on the card is erased. This occurs each time you insert a card and select it on the Optional Disk Configuration page.

Kernel core-dump files will be automatically saved to the flash-memory PC card.You can use the following CLI command to save kernel core-dump files to a flash-memory PC card:set optional-disk device-id ID type kernel-dump on

You can learn the appropriate device ID by enteringshow optional-disks

Transferring Kernel Core DumpsIf your system creates a kernel core-dump file and saves it on a flash-memory PC card, you can transfer it to a remote FTP server so that it can be sent to Check Point for analysis. You can configure the system to do this automatically by using the Core-Dump Server Configuration page (System Configuration -> Remote CoreDump Server). You must use Network Voyager—you cannot use the IPSO CLI.You must use FTP to transfer kernel core dumps (do not use TFTP), and you must enter a directory path to the location on the FTP server where core dumps should be saved. Do not leave the Directory Path field empty.IPSO uses the user name anonymous and the password passwd to log into the remote server anonymously. If your FTP server does not allow this user name and password for anonymous logins, you must create a user with this user



name and password to allow IPSO to transfer application and kernel core files to the server. <PR 59010>

Kernel core dump files are sent to the remote server after the system recovers from the problem that caused the core dump. You can verify that the core file was successfully transferred by checking the log message file for a message similar to the following: [LOG_NOTICE] xfer_crash: Transferred kernel core file to ftp_server_IP_address

This message is not displayed on the console.If the system attempts to transfer a kernel core dump file to a remote server but is unsuccessful for any reason, IPSO displays the following messages in the log message file and on the console:Syntax error, command unrecognized Oct 3 23:41:30 csim-phoenix22

[LOG_ERR] savecore: ftp_server_IP_address: check your username/password Oct 3 23:41:30

The second message appears even if the user name and password are correct.If you want to manually transfer a kernel core dump file to a remote FTP server, enter the following command at the IPSO shell prompt:savecore -r ftp://

username:password@ftp_server_IP_address/directory/

Enhancement for Policy Based RoutingWith IPSO 4.2, you can exert detailed control over traffic forwarding by using policy based routing (PBR). When you use PBR, you create routing tables of static routes and you direct traffic to the appropriate tables by using an access control list (ACL). Using an ACL in this way lets you direct traffic flow by filtering on one or more of the following:

Source addressSource mask lengthDestination address



Destination mask lengthSource portDestination portProtocol type

Combining PBR with Other RoutingYou can use policy based routing in combination with routing protocols or static routes configured in the normal way. To set this up, make sure that the action of the last rule in your ACL is Accept. This causes all packets that are not forwarded using a PBR table to be forwarded according to the standard routing configuration. If you employ a routing protocol that uses multicast addresses to form adjacencies (OSPF or RIP, for example), configure a rule in the ACL with the following settings:

Action: AcceptSrc IP Addr: 0.0.0.0Dest IP Addr 224.0.0.0Dest Mask Len: 4

This rule should be next to last in the ACL.You cannot use PBR to route locally destined packets, locally originated packets, multicast packets, or broadcast packets. You can configure an ACL rule to match this traffic, but the traffic will not be forwarded by a PBR table.

Creating a PBR TableTo configure a policy based routing table, follow this procedure:1. In Check Point Network Voyager, navigate to the policy based routing

page: Configuration > Traffic Management > Policy Based Routing.2. Enter a unique name for the policy based routing table in the text box and

click Apply.



Additional fields appear. (See Table 4 for more information on the parameters.)

3. Configure the table as appropriate.4. Click Apply.5. Click Save to make your changes permanent.

Table 4 Policy Based Routing Configuration Parameters


On/Off Clicking On enables the policy based static route. Clicking Off disables the static route.

Next hop type (Default Gateway) Specifies the next hop type for the static route. The following are the types:• Normal• MultipathThe default is Normal.



Next hop select This option is available only if the next hop type is Multipath. The options are:• None: Traffic is dropped. Use this

option to prevent this route from being used.

• scrdsthash: The system chooses the outgoing interface based on a hash of the source and destination addresses.

• srchash: The system chooses the outgoing interface based on a hash of the source address.

• dsthash: The system chooses the outgoing interface based on a hash of the destination address.

• roundrobin: The system chooses the outgoing interface based on a round robin method.

The default is None.

Description Specifies a unique description about the PBR static route.

Next hop type (New route) Specifies the next hop type for the static route. The following are the types:• Normal• Reject• Blackhole• MultipathThe default is Normal.





Deleting a PBR TableTo delete a policy based routing table, follow this procedure:1. In Check Point Network Voyager, navigate to the policy based routing

page: Configuration > Traffic Management > Policy Based Routing.2. Click the link of the policy based routing table to be changed.

Gateway type Specifies the type of additional gateways that will be used for equal-cost path splitting to the PBR static route. The following are the options:• Gateway Address: Specifies the IP

address of the gateway to which packets for this PBR static route are sent. The address must be the address of a router that is directly connected to the system you are configuring.Range: Dotted-quad (0-255. 0-255. 0-255. 0-255.) No default.

• Gateway Logical: Specifies an unnumbered interface as the next hop gateway.

New route Specifies the network address of a new static route. The static route cannot have host bits set, that is, there should be no bits in the address set beyond the specified mask length.Range: Dotted-quad (0-255. 0-255. 0-255. 0-255.)

Mask length Defines the mask length for the new static route.Range: 0-32.





3. Delete all configured routes by selecting Off in the Gateway column.4. Click the Delete check box.5. Click Apply.6. Click Save to make your changes permanent.

Configuring an Access Control List for PBRWhen you define an ACL, make it as restrictive (specific) as possible. For example, if you are using PBR to route HTTP traffic only, define the ACL with the port number for HTTP and protocol value for TCP.

NoteFor more information on configuring access control lists, see the Check Point Network Voyager Reference Guide for IPSO 6.2http://supportcontent.checkpoint.com/documentation_download?ID=10293.

To create an ACL for use with policy based routing, follow this procedure:1. In Check Point Network Voyager, navigate to the access control list page:

Configuration > Traffic Management > Access List.2. Enter a unique name in the Create a new Access List text box.3. Click Apply.4. Click the link in the ACL Name column.5. Select the interface from the Add Interface drop-down list.6. Select the direction from the Direction drop-down list.7. Check the Add Rule Before check box and click Apply.8. In the Action column, select PBR and click Apply.9. In the Policy Based Routing Table column, select the name of the

appropriate policy based routing table.10. Complete the configuration of the rule so that it matches the appropriate

traffic.




11. Click Apply12. If you use a routing protocol that uses multicast addresses to form

adjacencies, create a rule as described in “Combining PBR with Other Routing” on page 75.

13. Set the action of the last rule appropriately:If you use ACLs only for PBR, you probably want the action of the last rule to be Accept (so that the system forwards non-matching traffic).If you use ACLs for PBR and also to filter other traffic (that is, use ACLs for their traditional purpose), you might want the action of the last rule to be Drop.

14. Click Save to make your changes permanent.

Using PBR with VRRP and IP ClusteringIf you use PBR in combination with VRRP or IP clustering, follow these guidelines:

To use PBR in a VRRP configuration, you must configure PBR and the ACL on the master and backup nodes.With IP clustering, you can use Cluster Voyager to configure PBR (so that you configure it only once), but you must configure an ACL on the individual nodes. If you use PBR with IP clustering in forwarding mode, apply the PBR ACL on the cluster protocol network interfaces.

Policy Based Routing CLI CommandsThis section describes command line interface commands you can use to configure PBR.Use the following commands to create a PBR table.



add pbr table pbr_namenetwork ip_addressnetmask mask_length

Use the following commands to configure PBR

set pbr table pbr_namedefault comment commentdefault nexthop gateway address ip_addressdefault nexthop gateway logical unnumbered_ifdefault nexthop-select multipath_typedefault nexthop-type typedefault route <on | off>network ip_address netmask mask_length comment comment

network ip_address netmask mask_length nexthop gateway address ip_address

network ip_address netmask mask_length nexthop gateway logical unnumbered_if

network ip_address netmask mask_lenght nexthop-select multipath_type

network ip_address netmask mask_length nexthop-type type

Use the following commands to delete a PBR configuration.

delete pbr table pbr_namedefault nexthop gateway address ip_addressdefault nexthop gateway logical unnumbered_ifnetwork ip_address netmask mask_length nexthop gateway address ip_address

network ip_address netmask mask_lenght nexthop gateway logical unnumbered_if

Use the following commands to show information on your PBR configuration.



show pbr table pbr_namedefault nexthop-selectdefault nexthop-typedefault routenetwork value netmask mask_length nexthop-selectnetwork value netmask mask_length nexthop-type

Table 5 Policy Based Routing CLI Arguments

pbr table pbr_name Specifies the name of the table. Use alphanumeric characters.

network ip_address Defines the IP address of a new static route. The static route should not have any host bits set, that is, there should be no bits in the address set beyond the specified mask length.Range: Dotted-quad (0-255. 0-255. 0-255. 0-255.) No default

netmask mask_length Defines the mask length for the new static route.Range: 0-32No default.

default comment comment

Specify a unique description about the PBR static route.

default nexthop gateway address ip_address

Gateway Address: Specifies the IP address of the gateway to which packets for this PBR static route are sent. The address must be the address of a router that is directly connected to the system you are configuring.Range: Dotted-quad (0-255. 0-255. 0-255. 0-255.) No default.

default nexthop gateway logical unnumber_if

Gateway Logical: Specifies an unnumbered interface as the next hop gateway.



Enhancement for RIP Route Tags <PR 56709>

If a Check Point platform running a previous build of IPSO 4.2 receives a route tag in a RIP update, it does not pass the tag along in RIP updates that it sends out. Systems running Build 069 and later do propagate these tags when sending RIP updates.

default nexthop-select multipath_type

This option is only available if the next hop type is Multipath. The following are the options:• None: Traffic is dropped. Use this option to

prevent this route from being used.• scrdsthash: The system chooses the

outgoing interface based on a hash of the source and destination addresses.

• srchash: The system chooses the outgoing interface based on a hash of the source address.

• dsthash: The system chooses the outgoing interface based on a hash of the destination address.

• roundrobin: The system chooses the outgoing interface based on a round robin method.

The default is None.

default nexthop-type type

Specifies the next hop type for the static route. The following are the types:• Normal• Reject• Blackhole• MultipathThe default is Normal.

default route <on | off>

On enables the configured policy based static route. Clicking Off disables the static route.



Supports IP2450IPSO 4.2 Build 051 a03 and later supports the release of the Check Point IP2450, a two rack unit network security appliance that delivers more than 8 Gbps of large packet and 500 Mbps of small packet throughputand as much as 20 Gbps of large packet throughput and 5 Gbps of small packet throughput when equipped with two next generation Check Point accelerated data path (ADP) cards. These optional ADP cards are available with 12 ports of auto-sensing Gigabit Ethernet in 1000Base-T copper and 1000Base-X interchangeable SFP modules for SX, LX and copper interfaces. You can also purchase 10 Gigabit Ethernet ADP cards that have 3 ports and support XFP modules for SR, LR-10 kilometer, and LR-40 am fiber. The IP2450 delivers maximum business continuity through features such as redundant dual and hot-swappable power supplies, hot-swappable fan trays, and optional redundant hard disk drives with RAID level 1. For optimal reliability, Check Point offers the IP2450 in a flash-based configuration, and it is available in a disk-based configuration as well. The IP2450 is fully compatible with existing Check Point-supported PMC interface modules, which provides investment protection by enabling you to reuse the equipment you already have. See the following sections for more additional information about the release of the IP2450 platform:

“Cabling an IP2450 Platform <PR 59433>” on page 189“Configuring Gigabit Ethernet Descriptor Size” on page 189 “IP2450 Limitations” on page 195

Routing EnhancementsIPSO 4.2 Build 051 a03 and later introduces the routing enhancements described in this section.



Support for PIM Over VTIsPrevious builds of IPSO 4.2 support route based VPNs by supporting virtual tunnel interfaces (VTIs). Route based VPNs offer the following advantages over domain based VPNs:

Resilience (because you can use dynamic routing protocols within the VPN)Simplicity of firewall configuration (because you can simply define VTIs instead of building explicit encryption domains)

With previous builds of IPSO 4.2, you can run OSPF and BGP over route based VPNs and you can also run OSPF over a route based VPN that is terminated by IPSO systems running VRRP in an active-passive configuration.IPSO 4.2 Build 051 a03 and later adds support for all modes of PIM (sparse, dense, dense with state refresh and source-specific multicast) over route based VPNs, including those terminated by active-passive VRRP configurations.A VTI must be an unnumbered interface. When the PIM virtual address option is enabled (required for VRRP), PIM starts running on the VTI only when the corresponding proxy interface has a VRRP virtual address available. This occurs only when the proxy interface is part of the VRRP master.

Support for OSPFv3 With VRRPv3Previous builds of IPSO 4.2 support OSPFv3 and VRRPv3 for IPv6, but they are not supported in combination. With IPSO 4.2 Build 051 a03 and later, you can use OSPFv3 with VRRPv3. To use OSPFv3 with VRRPv3, enable the Virtual Address option on the OSPFv3 configuration page (click Config > IPv6 Configuration > Routing Configuration > OSPFv3). If the configured interface is part of the VRRP master virtual router, OSPFv3 runs on the interface. When you enable the Virtual Address option, OSPFv3 uses VRRPv3’s virtual link-local address for the interface as the source of its control packets. This cannot be the automatically configured link-local address—that is, you must change the link-local address for the



interface to something other than the default. You must configure the same link-local address on all the routers in the VRRP group.VRRP installs the link-local address only on the master, so OSPFv3 runs only on that router. If a failover occurs, VRRPv3 installs the link-local address on the new master and OSPFv3 starts running on that system. Because OSPFv3 runs on one router at a time, there is no synchronization of OSPFv3 state between the VRRP group members.The CLI command is for enabling the Virtual Address option for OSPFv3 is:set ipv6 ospf3 interface log_if_name virtual-address <on | off>

When configuring VRRPv3 to work with OSPFv3 (click Config > IPv6 Configuration > Router Services > IPv6 VRRP), you must also configure VRRPv3 to accept connections to virtual IPv6 addresses by enabling the Accept Mode option. The corresponding CLI command is:set ipv6 vrrp6 interface log_if_name vrid <1-255> accept-mode <on | off>

Support for Removing Private AS Numbers from BGP Update MessagesIPSO 4.2 Build 051 a03 and later allows you to prevent private AS numbers from propagating to external BGP peers. An ISP can assign private AS numbers (64512 to 65535) to a customer in order to conserve globally unique AS numbers. When an ISP does so, a BGP update from a customer network to the ISP has the private AS number in its AS_PATH attribute. When the ISP propagates its network information to other ISPs, the private AS number would normally be included. To avoid this, you can configure IPSO to remove the private AS number from BGP update messages to external peers.



To configure IPSO to remove private AS numbers from BGP updates, enable the Remove Private AS option on the configuration page for an external peer. The equivalent CLI command is:set bgp external remote-as as_number peer ip_address removeprivateas <on | off>

If you enable this option, private AS numbers are removed from BGP updates according to the following rules:

If the AS_PATH includes both public and private AS numbers, the private AS numbers are not removed.If the AS_PATH contains the AS number of the destination peer, private AS numbers are not removed.If the AS_PATH includes confederations and all the AS numbers in the AS_PATH are private, all the private AS numbers are removed.

Support for BGP Route RefreshIPSO 4.2 Build 051 a03 and later supports the ability to dynamically send route updates to peers, request BGP route updates from peers, and respond to requests for BGP route updates. For example, if you change the inbound routing policy, you can request that a peer readvertise its previously advertised routes so that the routes can be checked against the new policy. This feature is often referred to as a soft reset because it provides the ability to refresh routes received from a peer without tearing down the established session.These enhancements work only with peers that support the same capabilities. IPSO systems running IPSO 4.2 Build 051 a03 and later can also peer with systems that do not support these enhancements.



To configure BGP route updates, click the appropriate buttons in the Route Refresh section of the configuration page for a peer. The equivalent CLI commands are:set bgp external remote-as as_number peer ip_address send-route-refresh [request | route-update] [ipv4 | ipv6 | All] [unicast]

set bgp internal peer ip_address send-route-refresh [request | route-update] [ipv4 | ipv6 | All] [unicast]

Fix for shutdown Command <PR 58951>

If you use the shutdown command on a system running IPSO 4.2 Build 038 or later, the system requires you to enter additional input before it executes the command.This occurs only with Build 038 and later and does not occur with Build 042 HF003.

Fix for IP26x Battery Error Message <PR 59228>

On IP260 and IP265 systems running previous builds of IPSO 4.2, you might see an error message indicating that the voltage of the battery that powers the system clock is low when this is not true. Build 042 HF003 fixes this issue. When running this build, IP260 and IP265 systems do not display this error message when the battery is sufficiently charged.

Fix for Interface-Related Crash <PR 59635>

Systems running previous builds of IPSO 4.2 can crash and restart as a result of a problem that sometimes occurs if you delete the physical configuration information of an interface that you warm swapped out of the system. If this



crash occurs, you see console messages that begin with something similar to the following:#0 0x6b260 in ParseInterface (221a60, 0, 9, 22adc0, 141d20, 22adc0, 1ae000, 0)

#1 0x68b26 in logging_of_mgmt_activity (0, 22adc0, 22adc0, 61123, 1, 1, 1, 0)

Build 042 HF003 fixes this issue.

Fix for Rare Memory Issue <PR 58968>

Systems running previous builds of IPSO 4.2 can experience performance degradation or crashes caused by a rare scenario in which memory consumption is excessive.This problem can occur if IPSO flows is enabled (and therefore SecureXL is disabled) and there is a very large number of connections to connected hosts, as might be the case if there is a large number of connected hosts and there are many SMTP connections to them. In this circumstance the route table can become so large that a memory shortage results.Build 042 HF003 fixes this issue. IPSO 4.2 Build 042 HF002 and later, in combination with Check Point NGX R65 and disk-based Check Point security platforms, supports unified threat management (UTM). UTM provides anti-virus and URL filtering protection at the gateway so you can define policies that protect your network from spyware and viruses. Anti-virus scanning includes the ability to scan email (SMTP and POP3), Web (HTTP), and FTP traffic in real time for possible threats. URL filtering is based on an extensive database of threat categories and associated URLs.

NoteIf you upgrade from any NGX version to NGX R65, you can install and initially configure the UTM features.



Fix for Panic on IP225x Halt or Reboot <PRs 58965, 59158,

59161, 59162>

If you halt, shutdown, or reboot an IP2250 or IP2255 platform running IPSO 4.2 Build 041, the system panics and reboots again and you see console error messages that begin with the following: Fatal trap 12: page fault while in kernel mode

fault virtual address= 0x0

fault code= supervisor write, page not present

This problem occurs only with Build 041 and is fixed in Build 042 HF002 and later.

Supports IP690IPSO 4.2 Build 041 and later supports the new Check Point IP690 platform, which delivers a combination of high port density and performance in a single rack unit system. The IP690 supports as many as 16 Gigabit Ethernet ports and provides a maximum of 7 Gbps of firewall throughput. The platform is available in disk-based and flash-based configurations. If you choose a flash-based system, you can install a hard disk to increase the local storage available for log files. You can optimize the reliability of a disk-based IP690 by purchasing an optional mirror disk. In addition, all IP690 systems (disk-based and flash-based) come with dual, hot-swappable power supplies to provide maximum business continuity.

NoteAt this time, the IP690 does not support USB connections.



Supports Flash-Based IP290IPSO 4.2 Build 041 and later supports flash-based versions of the new Check Point IP290 platform, a half rack mountable unit purpose built for Check Point security applications. Because they do not use spinning media, flash-based platforms offer the greatest reliability. Flash-based platforms have a relatively small amount of storage for log files. You can increase the local storage available for log files in an IP290 by installing an optional hard disk.

Memory Enhancement for IP350 <PR 58785>

IP350 platforms running earlier builds of IPSO 4.2 can use a maximum of 512 MB of RAM. Build 041 and later allows these platforms to use as much as 2 GB of RAM.

Fix for IP290 VPN Performance Issue <PR 58383>

Installing a hardware encryption accelerator in an IP290 running IPSO 4.2 Build 038 significantly degrades the UDP throughput of the system. Build 041 and later fixes this problem.

Fix for IP IP290 Cluster Issue <PRs 58262, 58651>

If you use IP clustering with IP290 systems running IPSO 4.2 Build 038, a node might repeatedly leave and rejoin the cluster if it receives more traffic than it can process (the IP290 has a theoretical maximum of 1.5 Gbps). If this occurs, you see console messages similar to the following on the master node:[LOG_ERR] ipsrd[287]: CLUSTER: Failed to send App. message[1/3] to 2:No such process




Performance Fix for Disk-Based PlatformsIf you use previous builds of IPSO 4.2 with a disk-based platform and disable the SNMP disk failure trap (the default setting), the throughput of the system can be degraded for smaller packets. Build 041 and later fixes this problem.

Fixes for IP225x ADP Issues <PRs 57761, 58051>

The ADP subsystems in IP2250 and IP2255 platforms running earlier builds of IPSO 4.2 can crash if there is a very large number of connections and the rate of connection establishment is simultaneously very high. If this rare panic happens, you see console messages similar to the following:conn_alloc: out of connections

flow statistics:

hash index 12

flow d2152858 next d2152858 <216.130.193.60167.206.245.71 0 11 35319 53>

hash index 14

flow d016acf8 next d016acf8 <167.206.245.4 68.192.68.148 0 11 33149 53>

hash index 2e

flow d13e0ec0 next d13e0ec0 <69.115.146.252 167.206.245

cpu0 panic: watchdog interrupt cpu 0

945472 conn pool

0 conn free

200682 flows

2551614 added

104078 added with collision

2350932 deleted

7339970 lookup success

2611678 lookup fails



To restore the ADP subsystem to service after this crash occurs, you must restart the platform.The ADP subsystems in IP2250 and IP2255 platforms running earlier builds of IPSO 4.2 can also crash under specific circumstances related to memory allocation and deallocation for next hop addresses. This problem is much more likely to occur if there is a large amount of multicast traffic. If it does occur, the interfaces on the relevant subsystem are deactivated, and you must restart the platform to resolve the issue.IPSO 4.2 Build 041 and later fixes these problems.

Fix for IP225x Crash <PRs 58602, 58730>

If you have an encryption accelerator installed in an IP2250 or IP2255 platform running an earlier build of IPSO 4.2 and Check Point’s NG AI R55p, the system can experience a problem when attempting to encrypt or decrypt packets between 1600 and 2000 bytes in size. In this situation, an ADP subsystem or IPSO itself might crash. You must restart the platform to resolve the problem.IPSO 4.2 Build 041 and later fixes this problem. The issue does not occur with versions of the firewall other than NG AI R55p.

Fix for VPN-Related Panic <PR 58853>

If a system running IPSO 4.2 Build 038 is a VPN endpoint and dynamic routing is configured on a VPN interface, the system can panic and restart if the routes for the interface change. This problem occurs only with Build 038 and is fixed in Build 041 and later.

Fix for High CPU Utilization <PR 58683>

With systems running previous builds of IPSO 4.2, a problem can occur if you have a routing configuration such that packets for a connection exit one interface of a Check Point system and return packets for the connection enter



through a different interface. In this situation, the Check Point system might experience very high CPU utilization while these connections exist.IPSO 4.2 Build 041 and later fixes this problem.

Fix for GRE Tunnels <PR 58838

If a system running a previous build of IPSO 4.2 terminates a Generic Routing Encapsulation (GRE) tunnel and receives fragmented packets through the tunnel, it does not forward all the fragments. Build 041 and later fixes this problem.

Fix for Excessive Error Messages <PR 58808>

On IP2250 and IP2255 platforms running IPSO 4.2 Build 038, you might see a large number of the following error message recorded by syslog:adpsxl_getstats_reply:acp and cp mismatching!

This message is harmless and can be ignored, and it appears only on systems running Build 038. It does not appear on systems running Build 041 and later

Supports IP290IPSO 4.2 Build 038 and later supports the new Check Point IP290 platform, a half rack mountable unit purpose built for Check Point security applications. With six built-in 10/100/1000Base-T (RJ45) Ethernet ports and an empty PMC slot for optional interfaces, it delivers an expandable and scalable platform for all your enterprise branch office or small enterprise security needs. It provides a maximum of 1.5 Gbps of firewall throughput (unencrypted) and a maximum of 1 Gbps of VPN throughput (with optional encryption accelerator).The IP290 is initially available in a disk-based configuration and will later be available in flash-based configurations. You can add an optional internal VPN encryption accelerator and the following network interface modules:



Two port 1000Base-F multimode fiber opticTwo port Gigabit Ethernet copper

The IP290 is a half rack unit (RU) wide and one RU tall. By using dual shell mounting hardware, you can mount two IP290 platforms in a single rack space.

NoteAt this time, the IP290 does not support USB connections.

Fix for Issue with RADIUS and Clusters <PRs 57619,

58428>

If you use RADIUS authentication with a previous build of IPSO 4.2, you might not be able to use a browser to log into cluster nodes as a cluster administrator or administrator user. If this problem occurs, you can log in as a cluster administrator or administrator user using Telnet or SSH and use the CLI to manage the nodes or cluster.IPSO 4.2 Build 038 and later fixes this issue.

Fixes for Cluster Reboots <PRs 58355, 58398>

If you use IP clustering with previous builds of IPSO 4.2, the cluster master might reboot if a member leaves the cluster. A separate issue can cause any node (master or member) to reboot if a cluster interface is repeatedly deactivated and reactivated (flaps).IPSO 4.2 Build 038 and later fixes these rare issues.



Fixes for IP225x Panics IP2250 and IP2255 systems running previous builds of IPSO 4.2 can panic and reboot if the Delayed Notification option is enabled. Build 038 and later fixes this rare issue. <PR 58259>

Delayed Notification improves performance by reducing the amount of required communication between IPSO and the firewall and reducing the amount of synchronization between the members of IP clusters or VRRP groups, thereby reducing overhead processing. It is particularly beneficial when a system processes many short-lived connections. This option is enabled by default. To disable it as a workaround, access Configuration > Advanced System Tuning in Network Voyager.Build 038 and later also fixes a panic that can happen when IPSO does not properly handle an error message sent by an ADP subsystem. <PRs 57191, 58419>

Fix for IP225x Fiber GigE Link Issue <PR 57916>

IP2250 and IP2255 systems running previous builds of IPSO 4.2 might not be able to establish a link over a fiber optic Gigabit Ethernet connection if autoadvertise/auto negotiate is disabled on the interface at the other end of the connection. On Check Point systems running previous builds of IPSO 4.2, autoadvertise is enabled automatically for this type of interface and cannot be disabled. With Build 038 and later, you can disable autoadvertise for fiber optic Gigabit Ethernet interfaces, which fixes this problem and allows the link to be established.

Fix for IP225x Display Issue <PR 58151>

With previous builds of IPSO 4.2, Network Voyager and the IPSO CLI incorrectly identify 10 Gigabit multimode fiber optic interfaces as single mode fiber optic interfaces. This display problem occurs only on IP2250 and



IP2255 systems and has no effect on the functionality or performance of the interfaces.IPSO 4.2 Build 038 and later fixes this issue.

Fix for Encryption-Related Crash on IP1220/IP1260 <PR 57918>

IP1220 or IP1260 systems with a hardware encryption accelerator and running a previous build of IPSO 4.2 can crash and restart if a rare problem occurs during connection deletion. This problem occurs only if the system does not completely establish an encrypted connection and then attempts to delete the incomplete connection.IPSO 4.2 Build 038 and later fixes this issue.

Fix for Issue with Hardware Acceleration Statistics <PR 57389>

With previous builds of IPSO 4.2, if you enter the CLI commandshow cryptaccel statistics

on an IP560 or IP1200 Series platform that has a hardware cryptographic accelerator installed, IPSO does not return any information about the performance of the accelerator.IPSO 4.2 Build 038 and later fixes this issue.



Fix for IP260 Shutdown Issue <PR 58018>

When running previous builds of IPSO 4.2, certain IP260 platforms do not properly respond if you enter a halt or shutdown command. If the problem occurs, you see the following console messages:/dev/wd0f on /mnt: Incorrect super block.

Error: /image on /dev/wd0f

does not exist or is not a file

umount: /mnt: not currently mounted

boot failed

If you see these messages you must power cycle the system to restore it to service.This problem occurs on IP260 platforms that conform to the Reduction of Hazardous Substance (RoHS) initiative. (This is a European Union mandate that specifies that hazardous substances, such as lead, must be removed from the manufacturing process of products.) The problem does not occur on IP260 platforms that are not RoHS compliant.Build 038 and later fixes this issue.

Fix for PPPoE-Related CLI Command <PR 57517>

With previous builds of IPSO 4.2, you cannot use the IPSO CLI to specify a Point-to-Point Over Ethernet (PPPoE) logical interface as a gateway address when creating a static route. You can use Network Voyager to accomplish this.Build 038 and later fixes this problem.

Transparent Mode Supported on IP225x <PRs 57286,

57780, 57781, 57783>

When you enable transparent mode on interfaces, they forward traffic like a layer 2 device—they do not need IP addresses. Using transparent mode can



help you fit a firewall into a LAN without reconfiguring the network or allow you to maintain an existing IP address provided by your ISP. Previous versions of IPSO and IPSO 4.2 Build 029 do not allow you to use transparent mode with IP2250 and IP2255 platforms. With IPSO 4.2 Build 031 and later, you can use transparent mode with these platforms.

Enhancement for Daylight Savings Time <PR 58031> Since the release of IPSO 4.2 Build 029, a number of countries have revised their daylight savings rules to comply with changes implemented in 2007. IPSO 4.2 Build 031 and later includes updated information about daylight savings time in various countries.

PIM Supported with Cluster Forwarding Mode <PR

58060> With IPSO 4.2 Build 031 and later, you can enable Protocol-Independent Multicast (PIM) with IP clusters running forwarding mode. IPSO 4.2 Build 029 and previous releases of IPSO do not support this combination.

Fixes for Security VulnerabilitiesIPSO 4.2 Build 031 and later includes fixes to security vulnerabilities that affect several components of IPSO. You can find information about these vulnerabilities at the following Web sites:

OpenSSL-Related Vulnerabilities http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-2940 <PR 57305>

http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-3738 <PR 57303>




http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-2940






OpenSSH-Related Vulnerabilityhttp://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-5051 <PR 57405>

Apache-Related Vulnerabilityhttp://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-3918 <PR 57995>

Fix for Issue with Fresh Installation <PR 57892>

You cannot perform a fresh installation of IPSO 4.2 029 (use the boot manager to install IPSO) on any of the following platforms if the system has less than 512 megabytes of memory:

IP350IP355IP380IP385

To upgrade these systems to IPSO 4.2 029, you must use Network Voyager, the CLI, or the newimage shell command.This constraint does not exist with IPSO 4.2 Build 031 and later. You can perform a fresh installation of this build on these platforms even if the system has less than 512 megabytes of memory.

Fix for Crash Caused by Port Address 0 <PRs 56726,

57988> Systems running IPSO 4.2 Build 029 might crash and restart if both of the following are true:

You disable the SmartDefense Packet Sanity option in the firewall or you set this option to Monitor Only.The system receives traffic with a source or destination port address of 0.





This problem does not occur if the firewall does not create a SecureXL template for the connection—for example, a template is not created if the connection is NATed or encrypted.This issue is fixed in Build 031 and later.

Fix for Cluster Master Reboot <PR 57819>

If you have an IP cluster on systems running IPSO 4.2 Build 029, the cluster master might reboot if a node joins the cluster at a time when the master has allocated all the “buckets” it uses to assign connections. This is a rare circumstance.This issue is fixed in Build 031 and later.

Fix for Issue with VRRP and Transparent Mode <PR

57930>

If you use the Virtual Router Redundancy Protocol (VRRP) with transparent mode and PIM is enabled on system running IPSO 4.2 Build 029, all the systems in the VRRP group crash and restart if any of the VRRP nodes receives multicast traffic. This issue is fixed in Build 031 and later.

Fix for Cluster Forwarding Mode Issue<PRs 57847, 57848> If you use IP clustering in forwarding mode on systems running IPSO 4.2 Build 029, a problem can occur if an external interface on a cluster member (not the master node) fails while the member is receiving multicast traffic for a multicast receiver protected by the cluster. In this circumstance, the IPSO routing daemon crashes and restarts on the member.

This problem does not occur if the cluster master is receiving multicast traffic and its external interface fails. It does not occur if you use any of the other cluster modes.



This issue is fixed in Build 031.

Fix for SecureXL-Related Diagnostic Command <PR 58017>

If you use the command fwaccel templates to view templates created by SecureXL for acceleration purposes, systems running IPSO 4.2 Build 029 do not return valid results.This issue is fixed in Build 031 and later.


2 New Features in Check Point IPSO 4.2

Check Point IPSO 4.2 includes the following new features and enhancements: SecureXL Enabled by DefaultEnhanced Password ConfigurationHigh-Availability EnhancementsSupport for Check Point Local Logging on Optional DisksEnhancements for Time ConfigurationEnhanced Traffic Management (QoS)Voyager and CLI EnhancementsSNMP EnhancementsLogging EnhancementsEnhancements for Multicast RoutingEnhancement for OSPFLink Aggregation ChangesEthernet Link RedundancyEnhancement for GigE Interfaces <PR 56460>Modem Dialback EnhancementGTP Acceleration with SecureXLSupport for Long Range Ethernet NICsMobile IPv4



Transparent Mode on IP225x <PRs 57780, 57781, 57783>

SecureXL Enabled by DefaultWith previous versions of IPSO, Check Point’s SecureXL acceleration functionality is disabled by default on all platforms except the IP2250 and IP2255, which require SecureXL to achieve their high performance. With IPSO 4.2, SecureXL might be enabled by default on all platforms, depending on the following:

If you perform a fresh installation of IPSO 4.2 (use the boot manager to install IPSO), SecureXL is enabled by default even if it was disabled before you performed the upgrade. If you upgrade to IPSO 4.2 by using Voyager, the CLI, or the newimage command, the configuration of SecureXL is not changed. If it is disabled before you upgrade, it remains disabled after the upgrade.

If you want to disable SecureXL, you must run Check Point’s cpconfig command line utility.

Enhanced Password ConfigurationIPSO 4.2 provides for improved security by enhancing your ability to manage the passwords of system users. With this release, you can:

Specify rules for password creation so that passwords must meet a minimum standard for strength.Force users to change passwords at specified intervals.Track password use and prevent reuse of old passwords.Lock users out of a system if they fail a specified number of login attempts.


High-Availability Enhancements

High-Availability EnhancementsIPSO 4.2 includes new features and enhancements for the high-availability configurations that you can create using IP clustering and Check Point’s implementation of the Virtual Router Redundancy Protocol (VRRP).

Unicast Clustering ModeIPSO 4.2 includes a new IP clustering mode that combines the benefits of multicast mode and forwarding mode.The cluster multicast modes usually offer the best cluster performance. However, these modes associate multicast MAC addresses with cluster IP addresses, and some routers do not automatically update their ARP tables when they receive packets with this combination. In this case, you must manually add static ARP entries to the routers so that they can send traffic to the cluster. The new mode—unicast mode—provides the performance of multicast mode but does not require you to add static ARP entries to routers because it associates unicast MAC addresses with cluster IP addresses.

Support for External Load BalancersWith IPSO 4.2, you can use an external load balancer to balance traffic to multiple IPSO firewalls without using IP clustering or VRRP. By configuring the firewalls to synchronize traffic with each other you can provide high availability as well. Using an external load balancer also has the advantage of not requiring you to use virtual IP addresses on the IPSO firewalls. You can enable this new feature on the Configuration -> High Availability -> External Load Balancer Support page.If you use an external load balancer, be aware that this product must be capable of detecting a firewall failure and adjusting its balancing decisions accordingly.Below are some details about how to use Check Point’s SmartDashboard to configure the firewall to work with a load balancer:



Create a gateway cluster.Do not use ClusterXL.Use the following settings on the 3rd Party Configuration tab:

Enable High Availability.Use Check Point VRRP or Other OPSEC as the 3rd Party Solution.Enable state synchronization.Leave the remaining options disabled.

Use the Edit Topology dialog box to perform the following:Define the internal and external interfaces as private.Define a synchronization interface that is separate from the internal and external interfaces.Do not define any other interfaces.

NoteBe sure to connect the synchronization interfaces.

The following firewall features are not supported or are partially supported if you use an external load balancer:

ConnectControl is not supported.NAT is partially supported (asymmetric connections are not supported). VPNs are partially supported (asymmetric connections are not supported).Using a Virtual IP address on a cluster interface is not supported.

Single License VRRP

NoteThe Single License VRRP feature is not supported.


High-Availability Enhancements

With IPSO 4.2, you can use the Single License VRRP feature to create an inexpensive high availability configuration using a single Check Point firewall license. This is a low-cost solution because you can purchase only one firewall license. To take advantage of this solution, you create a VRRP pair and install a copy of the license on both systems. Only one node (and one copy of the firewall license) is active at one time.It is very easy to set up a single license VRRP configuration by following these basic steps:1. Configure VRRP appropriately on two systems.2. Configure the routers that connect to the VRRP pair to use the appropriate

backup addresses (virtual addresses) as next hops, just as you do with other VRRP configurations.

3. Install an identical copy of a firewall license in each system.4. Configure the firewall and push a policy.5. Enable the Single License VRRP feature.

Constraints with Single License VRRPYou should be aware of the following constraints before you implement this configuration:

You cannot include more than two platforms in the VRRP group.You must use an active-passive configuration. You cannot use an active-active setup.You cannot use firewall synchronization, so existing connections are not maintained in the event of a failover.When failover occurs, a relatively long time (compared to other VRRP configurations or an IP cluster) elapses between the failure on the original master and service beginning on the new master.Once a failover has occurred, failback does not happen in the same way as with other VRRP configurations. With Single License VRRP, failback occurs only if you fix the problem that caused the failover from the original master and then reboot the new master.



VRRP Hard-Disk Failure DetectionIf you use VRRP with IPSO 4.2 on a disk-based platform, you can configure the system to monitor the hard disk. If certain disk errors occur when this feature is enabled, all the virtual routers on the platform transition to initialized state, which causes a VRRP failover. If there is a disk mirror set in the platform and the source (primary) disk experiences one of these errors, the virtual routers do not transition to initialized state as long as the mirror disk functions correctly.

ARP Mirroring for VRRPWith previous versions of IPSO, there can be a slight delay in service when a VRRP failover occurs (when there is a change of master) because the new VRRP master might need to learn the MAC addresses that correspond to its next hop IP addresses before it can forward traffic. IPSO 4.2 lets you eliminate this delay by using a new option (ARP Mirroring for HA) to cause the VRRP-enabled interfaces on backup routers to have the same ARP information as the master, which eliminates the need to learn MAC addresses if there is a change of master.

Support for Check Point Local Logging on Optional Disks

IPSO 4.2 introduces full support for Check Point firewall logging on optional disks in flash-based platforms.To use an optional disk for storing Check Point logs locally, you must upgrade to IPSO 4.2 (or IPSO 4.1 Build 023) and install the appropriate Check Point version. As of the publication of this document, the only Check Point version that supports local logging on flash-based platforms is Check Point NGX R62 with a required hotfix applied. Please contact Check Point support for current information on Check Point versions that support local logging on optional disks.


Support for Check Point Local Logging on Optional Disks

Once you install the correct software, you enable Check Point logging by configuring the optional disk to store log files. Previously you had to perform additional steps beyond configuring the optional disk. This is no longer the case.

Using Network Voyager to Configure an Optional Disk1. In Network Voyager, access the Optional Disk page (Configuration >

System Configuration > Optional Disk).2. Select the Logs option for the optional disk.

If the optional disk is an unlabeled hard disk, you see a message saying so after the list of available optional disks. If you are sure that the optional disk is a supported disk, select the check box after the message in addition to the Logs option (you must select both). Doing so will force the system to label the hard disk and then configure it as an optional disk.

3. Click Apply.4. Wait until you see a message indicating that you should reboot the system.

In some cases there might be a long delay before the operation completes and the message appears. You can check on the status of the operation by clicking the Optional Disk link in the navigation tree, which causes the status message to update.

5. When the status message states the operation is complete, click Reboot, Shutdown System. The Check Point firewall can now log to the optional disk.

6. If you also want IPSO to log to the optional disk, access the System Logging configuration page (System Configuration > System Logging) and select the option Logging to Optional Disk.



Using the Boot Manager to Configure an Optional DiskWith the introduction of the Check Point versions that fully support logging to optional disk, you can now configure an optional disk for firewall logging as part of performing a fresh installation of IPSO using the boot manager. (PR 55515 has been resolved.)To configure an optional disk for logging while performing a fresh IPSO installation:1. Type y when the boot manager asks if you want to configure a device to

store logs.2. Enter the device ID when prompted.

NoteIf your optional disk is an unlabeled hard disk, the boot manager will list it as an unsupported device and will not let you configure it to store logs. In this case, continue with the installation of IPSO and then follow the procedure in “Using Network Voyager to Configure an Optional Disk” to configure your optional hard disk to store logs.

NoteIt might take as many as 90 minutes for the optional disk configuration to complete.

3. When the configuration operation completes, continue with the IPSO installation.

4. Log into Network Voyager after you complete the initial configuration and confirm the optional disk configuration by viewing the Optional Disk Configuration page.

5. If you also want IPSO to log to the optional disk, go to the System Logging configuration page (System Configuration > System Logging) and select the option Logging to Optional Disk.


Enhancements for Time Configuration

Enhancements for Time ConfigurationIPSO 4.1 allows you to use the CLI to configure daylight savings time (DST) rules to conform to changes in local practices. IPSO 4.2 adds the following enhancements for this feature:

You can use Network Voyager to create and configure DST rules.You can configure multiple DST rules per time zone.DST rules are retained if you upgrade IPSO.DST rules are retained if you restore a backup configuration file to a platform on which you performed a fresh installation of IPSO (you used the bootmanager install command).DST rules are a cluster join-time shared feature. You can modify the settings for the currently selected time zone without selecting another time zone and then reselecting the current one.

Enhanced Traffic Management (QoS)You can use the traffic management features in IPSO to provide different levels of service—or quality of service (QoS)—to different types of network traffic. Broadly speaking, you might want to employ traffic management to accomplish goals such as:

prioritizing mission-critical applicationsmaximizing your existing network infrastructure (and avoiding the expense and effort of upgrades)improving the performance of applications that are particularly sensitive to latencyresponding to unexpected traffic patterns in your network

IPSO provides several traffic management implementations. IPSO 4.2 includes enhancements for the Differentiated Services (DiffServ) implementation, which is useful for IP traffic. The DiffServ enhancements in IPSO 4.2 are:



congestion avoidanceassured forwarding per hop behavioradditional congestion management methodsDSCP marking applied before encryptionintegration with SecureXLprioritizing without shaping

NoteTraffic management features are not supported on IP2250 and IP2255 platforms.

Performance ConsiderationsWhen you enable QoS on any IPSO system there is some level of performance degradation for the affected traffic. If you use QoS only to classify packets the degradation is relatively small, but it can be significant if you also have the system prioritize traffic. You should employ this functionality only in circumstances in which the overall benefit outweighs the costs. For example, you might want to prioritize mission-critical traffic (such as VOIP traffic) that traverses a low bandwidth link, such as a T1 WAN connection. In this circumstance, the performance cost might be insignificant given the limitations of the narrow pipe. If you have a high bandwidth connection such as a Gigabit Ethernet link, the performance cost imposed by QoS is probably much more significant and is likely to be prohibitive. Your throughput will be affected by variables specific to your configuration, including packet sizes and traffic mix, so you should determine how QoS functions in your environment before deploying it in a production network.

Congestion AvoidanceWhen the amount of outgoing traffic exceeds the transmission capabilities of the interface it is attempting to transit, the interface is congested and packets


Enhanced Traffic Management (QoS)

are dropped. You can configure IPSO 4.2 to respond to congestion in a way that makes the most sense in your network environment.IPSO has two methods of deciding which packets to drop when egressing traffic congests an interface. Each method applies to a specific queue—that is, to a given class of traffic. The methods are explained below:

Tail drop: Tail drop simply discards any packets that arrive for a queue after the queue is full. By using tail drop you can possibly reduce the number of dropped packets, especially if you configure large queues. On the other hand, using large queues can incur increased delays (because more packets wait for the queue to be serviced).Using tail drop can also lead to inefficient use of link bandwidth because of global synchronization. This happens when the sliding window size for multiple TCP connections decreases simultaneously, with the result that all the senders send fewer packets per interval. If this occurs repeatedly, the average utilization of the link decreases.Weighted random early detection (WRED): When you enable WRED, IPSO monitors queues and drops packets according to a configurable scheme.WRED is based on the random early detection (RED) method, which drops packets before queues are filled based on configurable threshold values. This reduces or eliminates the potential for global synchronization because different senders do not see packets dropped simultaneously.WRED adds a weighting scheme that allows you to prioritize some traffic so that fewer of its packets are dropped. The weighting is based on the IP precedence value for a packet, which is controlled by the first three bits of the type of service field in the IP header. A greater IP precedence value results in a smaller probability of packets being dropped. (See RFC 791 for more information about IP precedence.)



Assured ForwardingIPSO 4.2 adds the assured forwarding (AF) per hop behavior, as defined in RFC 2597, to provide you with a finer-grained capability for managing traffic flows when egressing traffic congests an interface. When you use assured forwarding, you assign types of traffic to four AF classes, class 1 through 4. The classes are in descending order, meaning that class 4 has the highest priority and traffic assigned to this class is serviced before traffic assigned to the other classes. In addition to the four classes, assured forwarding provides three drop precedences—low, medium, and high—within each class. You can use these drop precedence levels to fine tune how an interface responds to congestion.You enable assured forwarding by assigning specified Differentiated Services Code Point (DSCP) values that specify an AF class and drop precedence in access control lists (ACLs). Traffic that matches the filters of an ACL and is marked with a DSCP should receive the assigned level of service by all DiffServ-enabled routers in the forwarding path.Table 6lists all the queues supported by the implementation of Differentiated Services in IPSO 4.2. Table 7lists the DSCP values to use to assign assured forwarding classes and drop precedences.

NoteYou must use hexadecimal notation to specify DSCP values.

.

Table 6

Queue Name Queue Priority DSCP Queue Specifier

Internetwork Control

0 0xc0 7

Expedited Forwarding

1 0xb8 6

AF Class 4 2 See Table 2 5


Enhanced Traffic Management (QoS)

You should assign DSCP 0xc0 to internetwork control traffic, such as routing messages. Locally originated internetwork control traffic is automatically assigned to the appropriate queue. Traffic assigned to queues 7 (internetwork control) and 6 (expedited forwarding) is always prioritized over AF traffic.

New Congestion Management MethodsWith IPSO 4.2, you can exercise control over how the available bandwidth is divided up among traffic classes by using the following scheduling disciplines on a per-interface basis:

Weighted round robin (WRR)Cascade




Best Effort 7 no value 0

Table 7

Drop Precedence AF Class 4 AF Class 3 AF Class 2 AF Class 1

Low 0x88 0x68 0x48 0x28

Medium 0x90 0x70 0x50 0x30

High 0x98 0x78 0x58 0x38

Table 6

Queue Name Queue Priority DSCP Queue Specifier



If you enable WRR, you assign weight values of 1-8 to individual queues. These values tell IPSO how much processing resources to allocate to each queue relative to the other queues being processed by that interface. For example, traffic assigned to a queue with a weight of 2 will receive twice as much processing resources as traffic assigned to a queue with a weight of 1. Traffic assigned to a queue with a weight of 3 will receive 50 percent more processing resources as traffic assigned to a queue with a weight of 2. Queues with greater weight values can send more bytes and packets per scheduling round.Cascade scheduling is similar to WRR but imposes the following constraints:

Queue 7 (priority 0) and queue 6 (priority 1) must be assigned the weight Strict Priority.You must configure the remaining queues so that their weights are in descending order. You can configure adjacent queues to have identical weights, but the weight assigned to a given queue cannot be greater than that assigned to a queue with a greater queue specifier.

DSCP Marking Before EncryptionIf a queued packet is destined for an IPSec tunnel, IPSO 4.2 applies the appropriate DSCP before the packet is encrypted. When it encrypts the packet, the firewall than copies the DSCP value to the header of the encrypted packet. The DSCP value is therefore visible to routers, which allows the packet to receive prioritized service as it transits the tunnel. Because DSCP values must be applied to packets before they are encrypted and packets are encrypted before egress, IPSO 4.2 can apply DSCP marking on ingress. Previous versions of IPSO do not allow packets to be marked on ingress.


Voyager and CLI Enhancements

Integration with SecureXLWith IPSO 4.2, DiffServ traffic management is integrated with Check Point’s SecureXL acceleration functionality. This allows you to manage the quality of service for traffic accelerated by SecureXL.

Prioritizing Without ShapingPrevious versions of IPSO require you to apply an aggregation class to any ACL rule that has the action prioritize. This requirement does not exist in IPSO 4.2.

Voyager and CLI EnhancementsIPSO 4.2 includes an number of enhancements for Network Voyager and the IPSO CLI.

HTTP Uploads: You can use HTTP instead of FTP when using Network Voyager to upload IPSO images, packages, or backup configuration files to a stand-alone IPSO platform. VRRP Quick Add Configuration: If you use the full monitored-circuit mode of VRRP configuration (not the simplified configuration method), you can use a new Quick Add box to configure VRRP interfaces without entering text in Voyager fields. To configure interfaces this way, use the following command format:interface-name mc virtual-router-id priority backup-address monitor-interface-name priority-delta <Enter>

You can configure as many interfaces as you want. Click Apply when you are done.Hosts Quick Add: With IPSO 4.2 it is easier to enter multiple host names and IP addresses by using a new Quick Add box on the Host Address page to add the names and addresses. Enter host names and addresses using the following command format:hostname IP-address <Enter>



You can enter as many pairs as you want. Click Apply when you are done.Banner and MOTD: Previous versions of IPSO do not allow you to configure the login banner that is displayed before a user logs into or out of the system. (The default text is “This system is for authorized use only.”) Previous versions do allow you to configure an FTP welcome message and a “message of the day” (MOTD) that users see when they log in using the command line, but you cannot use Voyager or the IPSO CLI to configure these messages. IPSO 4.2 lets you configure all of these messages using Voyager and the CLI.Statistics for Aggregated Links: IPSO 4.2 displays more information about aggregated Ethernet links on the Interface Traffic Statistics monitor page. You can now see which interfaces belong to an aggregation group and view statistics for the individual interfaces.CPU Utilization Percentages: IPSO 4.2 displays more information about CPU utilization. In addition to the load averages displayed in previous versions, IPSO 4.2 also displays various CPU utilization percentages on the CPU and Memory Utilization page.CLI Monitoring Enhancement: IPSO 4.2 improves the reporting capabilities of the CLI by allowing you to save reports to files and specify a delimiter to separate fields in the reports. For example, to create a memory utilization report and download it to a file, you could use the following command:Show monitor summary hourly memoryutilization delimiter <, | ; | Tab> filename name

Report files are saved in the directory /var/log/monitor.

SNMP EnhancementsIPSO 4.2 includes the following enhancements for Check Point’s implementation of the Simple Network Management Protocol (SNMP):

Implementation of RFC 3635: Previous versions of IPSO include an implementation of the SNMP MIB for Ethernet-like interface types


Logging Enhancements

defined in RFC 1650. IPSO 4.2 updates the implementation to comply with RFC 3635.Power Supply Traps: IPSO 4.2 includes two new SNMP traps to provide alerts when low voltage and high voltage conditions exist in power supplies. The traps SystemLowVoltage and SystemHighVoltage have been added to the IPSO System MIB.

Logging EnhancementsIPSO 4.2 increases the number of system events that are logged by the syslog daemon. The following events are now logged:

Voyager, IPSO shell, CLI, console, and modem logins and logoutsAll maintenance operation (upgrades, reboots, backups, and so on)All configuration changesAny time an interface is enabled or disabledAll VRRP transitionsAll SNMP traps Filesystem mounts and unmounts

IPSO 4.2 also provides an option that makes certain log messages more useful. When you enable the system configuration audit log, you see a new option that you can enable so that messages about system configuration changes are displayed in a textual format. This format is more informative because the messages are written in “plain English” and include additional information about the configuration changes. Table 8includes a few examples that show log messages in the previous style and the textual format.

Table 8 Log Message Formats

Previous Format Textual Format

process:pm:coreaction t PROCESS_CONFIG: Enabled system failure notification



(To view system configuration log messages, select the log type LOG_NOTICE or ALL on the System Message Log page.)

Enhancements for Multicast RoutingIPSO 4.2 includes several enhancements for multicast routing.

IGMP Local and Static GroupsWith IPSO 4.2 you can facilitate multicast routing by creating IGMP local and static groups. You create these groups on a per-interface basis, and for each group you specify an address for a multicast group. IPSO then acts as a receiver for that multicast group and builds a routing tree to the source regardless of whether there are any hosts on the downstream LAN that want to receive traffic for that group. When hosts later join the multicast group, they start receiving traffic sooner because the routing tree is already built.This feature is useful in any situation in which multicast receivers might not be permanently attached to the downstream LAN. For example, if you have laptop users who regularly detach from the LAN and reattach when they return to work you can create a local or static group for the multicast address that they receive traffic for. IPSO then maintains the reverse path forwarding tree without waiting for requests from the laptops.The differences between local and static groups are explained below.

When you create a local group: IGMP sends a membership report out of the appropriate interface.

ipsrd:instance:default:vrrp:nomonitorfw t VRRP_CONFIG: Disabled VRRP Monitor Firewall State

mcvr:vrid:123 Deleted Monitored-Circuit Virtual Router with vrid 123

Table 8 Log Message Formats

Previous Format Textual Format


Enhancements for Multicast Routing

If the system is running a parent multicast routing protocol, IGMP informs the parent protocol about the simulated local receiver.

When you create a static group:IGMP does not send a membership report for the group. You might want to use static groups if you do not want other devices to receive IGMP membership reports from your IPSO system. If the system is running a parent multicast routing protocol, IGMP informs the parent protocol about the simulated local receiver.

NoteIGMP local and static groups are supported in IP clusters.

IGMPv3 with PIM Source-Specific Multicast (SSM)IPSO 4.2 provides IGMP version 3 source filtering to support source-specific multicast (SSM), which enables the IPSO system to request traffic from specific sources via PIM join/prune messages without requiring the presence of a rendezvous point (RP). This enables the IPSO system to forward traffic from only those sources from which receivers requested traffic. IGMPv3 supports applications that explicitly signal sources from which they want to receive traffic. With IGMP version 3, receivers (hosts) identify their membership to a multicast group in the following modes:

Include mode: Receivers announce membership to a group and provide a list of IP addresses from which they want to receive traffic (the include list).Exclude mode: Receivers announce membership to a host group and provide a list of IP addresses from which they do not want to receive traffic (the exclude list). To receive traffic from all sources, a host sends an empty exclude list.



The multicast group address range 232/8 (232.0.0.0 to 232.255.255.255) is reserved for use by SSM protocols and applications. The DRs of senders do not send register packets to any RPs in the SSM group range. When SSM is enabled, all other multicast groups are treated as they are in normal sparse-mode.

PIM Dense Mode State RefreshPIM dense mode builds multicast distribution trees that operate on a flood and prune principle. Multicast packets from a source are flooded throughout a PIM dense mode network. PIM routers that receive multicast packets and have no directly connected multicast group members or PIM neighbors send a prune message back up the source-based distribution tree toward the source of the packets. As a result, subsequent multicast packets are not flooded to pruned branches of the distribution tree. However, the pruned state in PIM dense mode times out approximately every three minutes and the entire PIM dense mode network is reflooded with multicast packets and prune messages. This reflooding of unwanted traffic throughout the PIM dense mode network consumes network bandwidth unnecessarily.IPSO 4.2 includes a PIM Dense Mode State Refresh feature that keeps the pruned state in PIM dense mode from timing out by periodically forwarding a control message down the distribution tree. The control message refreshes the prune state on the outgoing interfaces of each router in the tree. This saves network bandwidth by greatly reducing the reflooding of unwanted multicast traffic to pruned branches of the PIM dense mode network.

NoteYou must enable state refresh on all the PIM routers in the distribution tree to take advantage of this feature.


Enhancement for OSPF

PIM Accelerated on All PlatformsWith previous versions of IPSO, Protocol-Independent Multicast (PIM) traffic is accelerated on the IP2250 and IP2255 platforms, but this feature is not available on other platforms. With IPSO 4.2, PIM acceleration is supported on the entire line of IPSO network security platforms when Check Point’s SecureXL functionality is enabled. Both Sparse mode and Dense mode traffic is accelerated.

Enhancement for OSPFAs explained in Appendix E of RFC 2328, an OSPF router can create separate LSAs for networks that have the same address but different masks by using host bits in the LS ID. Previous versions of IPSO comply with Appendix E by creating an LS ID and checking to see that is unique. If it is not unique, previous versions create another LS ID but do not check to see if this second LS ID is unique. If this happens and duplicate LS IDs are created, routing problems occur.IPSO 4.2 enhances Check Point’s implementation of OSPF to guarantee that LS IDs are always unique.

Link Aggregation ChangesCheck Point IPSO appliances allow you to aggregate (combine) Ethernet ports so that they function as one logical port. You get the benefits of greater bandwidth per logical interface and load balancing across the ports. For example, you can aggregate two 10/100 mbps ports so they function like a single port with a theoretical bandwidth of 200 mbps, and you can aggregate two Gigabit Ethernet ports so they function like a single port with a theoretical bandwidth of 2000 mbps. If you have only 10/100 interfaces and need a faster link but can’t or don’t want to use Gigabit Ethernet, you can use link aggregation to achieve faster throughput with the interfaces you already have.



Another benefit of link aggregation is redundancy—if one of the physical links in an aggregation group fails, the traffic is redistributed to the remaining physical links and the logical interface continues to function. IPSO 4.2 includes several changes to link aggregation, as explained below.

Dynamic Link AggregationPrevious versions of IPSO support the IEEE 802.3ad standard for static link aggregation. IPSO 4.2 also supports the 802.3ad Link Aggregation Control Protocol (LACP) for dynamic link aggregation, so you can now realize the benefits of dynamic link aggregation on devices connected to Check Point platforms.Regardless of whether you use static or dynamic link aggregation, you must configure the physical interface settings for both ends of the link identically. IPSO does not completely implement dynamic link aggregation. The IPSO implementation differs from the standard in that:

You must create a link aggregation group on your IPSO platform and assign it an IP address even when using LACP because the firewall requires an IP address for the group.You must add ports to the group manually.

Full Duplex Required <PR 57102>

Link aggregation requires all the physical configurations (link speed, duplicity, autoadvertise setting, and so on) to be identical for all the interfaces that participate in a given group. These settings must match the settings for the switch ports that the interfaces are connected to.IPSO 4.2 requires aggregated interfaces to use full duplex duplicity. Previous versions of IPSO allow aggregated interfaces to be half duplex. If you have a group with half duplex interfaces on a system running a previous version of IPSO and upgrade to 4.2, the group is active after the upgrade and continues to forward traffic. However, both of the following are true:


Ethernet Link Redundancy

You cannot add any interfaces to the original group.If you create a new link aggregation group on a system running IPSO 4.2, you cannot include half duplex interfaces in the new group.

Ethernet Link RedundancyWith IPSO 4.2, you can configure redundant Ethernet interfaces for resiliency purposes. For example, if you create a link redundancy group that includes two physical interfaces and the active interface fails, the second interface takes over and there is no interruption in service. You might want to use this feature if your IPSO platform is connected to a switch that does not support link aggregation.There are significant differences between link redundancy (Ethernet bonding) and link aggregation:

There is no load balancing within a link redundancy group—only one of the interfaces in a group is active at a given time. The interfaces in a link redundancy group do not need to be configured identically. For example, they can have different speeds and duplicity settings.You can include a link aggregation group within a redundancy group, but a redundancy group cannot be part of an aggregation group.

You can combine interfaces from different network interface cards in a single link redundancy group, and you can create as many as eight link redundancy groups per system. Each group can include as many as eight interfaces. (If you include a link aggregation group, it counts as one redundancy interface regardless of how many physical ports are in the aggregation group.) An interface can participate in only one redundancy group.On IP2250 and IP2255 platforms, link redundancy is subject to the same constraints as link aggregation:

Do not include interfaces on different ADP I/O cards in the same link redundancy group.



Do not combine any of the built-in Ethernet management interfaces with interfaces on an ADP I/O card to form a redundancy group.You can combine management interfaces to create a redundancy group.

When you create a link redundancy group, you must designate a primary interface. This is the default active interface—if the primary interface fails and later returns to service it becomes the active interface again. For this reason you should configure the fastest interface in the group to be the primary interface.With the original implementation of link redundancy, all the interfaces in a link redundancy group must connect to the same device at the other end of the link. You cannot configure a single redundancy group across multiple switches. Starting with IPSO 4.2 Build 078, this is no longer true—you can configure a single redundancy group across multiple switches.

Enhancement for GigE Interfaces <PR 56460>

With previous releases of IPSO, Gigabit Ethernet interfaces can drop packets under specific circumstances in which the CPU is too busy to service the interfaces in a timely fashion. This problem is most likely to occur if all of the following conditions exist:

There is a large amount of unaccelerated traffic.Most of the traffic transits two interfaces.Both interfaces are Gigabit Ethernet.

With IPSO 4.2, you can prevent this problem from occurring by increasing the number of descriptors that are available for Gigabit Ethernet interfaces. This allows the system to temporarily store more packets while waiting for the CPU to service them. The system uses one descriptor per packet unless it receives jumbo frames (Ethernet frames larger than 1518 bytes), in which case it uses multiple descriptors per packet. (You must explicitly enable support for jumbo frames by configuring the MTU for a Gigabit Ethernet interface to be greater than 1518 bytes.)


Modem Dialback Enhancement

You can configure the number of descriptors by entering a value in the Descriptor Size field on the Network Voyager page for configuring physical Gigabit Ethernet interfaces. The default value is 128. You can use the CLI to configure this value by entering the command:

set interface phys_if_name descriptor_size <128–512>

The value you enter in Voyager or the CLI must be a multiple of 8.This option is not available on IP2250 and IP2255 systems.

Modem Dialback EnhancementIPSO 4.2 allows you to insert commas into a modem dialback number to cause the dialing to pause briefly. You can enter multiple adjacent commas to increase the delay period.

GTP Acceleration with SecureXL Check Point and IPSO 4.2 support acceleration of GTP packets by SecureXL. GTP is a tunneling protocol that is used to establish links between a Serving General Packet Radio Service Node (SGSN) and a General Packet Radio Service Gateway Support Node (GGSN). Only GTP data traffic is accelerated. Signaling and connection control packets still go to the firewall for further inspection. SecureXL performs normal inspection on the GTP headers, detects and accelerates data traffic, and performs security checks. Packets that pass the security checks are forwarded from the SecureXL layer. Packets that fail any GTP security check are forwarded to the firewall for further inspection. SecureXL keeps track of the amount of GTP data being accelerated and updates the firewall periodically.



Support for Long Range Ethernet NICsIPSO 4.2 supports new single-mode fiber 1000BASE-LX Ethernet network interface cards for the following IP platforms:

IP390IP560IP1220IP1260IP2255

Mobile IPv4IPSO 4.2 includes an experimental implementation of Mobile IPv4 that has been integrated with Check Point’s SecureXL acceleration functionality and allows you to configure an IPSO platform as a home agent. There is no foreign agent support in this implementation.Please note that this implementation has not been qualified by Check Point.

CautionDo not enable Mobile IPv4 on an interface on which you have configured a DVMRP tunnel. The implementations are not compatible, and Mobile IPv4 does not work properly in this circumstance. <PR 59675>


When you enable transparent mode on interfaces, they forward traffic like a layer 2 device—they do not need IP addresses. Using transparent mode can help you fit a firewall into a LAN without reconfiguring the network or allow you to maintain an existing IP address provided by your ISP. Previous versions of IPSO do not allow you to use transparent mode with IP2250 and



IP2255 platforms. IPSO 4.2 allows you to use transparent mode with these platforms, but this feature is not supported at the time of publication of this document.




3 Performing the Initial Configuration

When you turn on a Check Point IP security platform for the first time, you must provide it with some initial configuration information. You can use two methods to perform the initial configuration:

In an automated fashion by using the built-in dynamic host configuration protocol (DHCP) client.Manually by using a console (direct serial) connection.

After you decide which method to use, follow the instructions in “Using DHCP to Configure the System” or “Using the Console to Configure the System” on page 135 to perform the initial configuration. Regardless of which method you use, see “Performing Additional Configuration” on page 139 for important information about how to proceed after you complete the initial configuration.This chapter contains the following sections:

Using DHCP to Configure the SystemUsing the Console to Configure the SystemRegistering the IP AppliancePerforming Additional Configuration



Using DHCP to Configure the SystemThe Check Point IPSO DHCP feature allows a properly configured DHCP server to provide your system with the following information:

Host nameIP addressDefault route

You can then use Check Point Network Voyager to reconfigure any of these settings. When you do so, Voyager keeps the modified settings. (DHCP is not used if configuration information already exists.) Your DHCP server automatically sets the administrative password of the IP system to password.To use DHCP to configure your system, perform the following steps (which are explained in the following sections):1. Configure your DHCP server.2. Run the DHCP client on the Check Point system.

Configuring Your DHCP serverConfigure a DHCP server with (at a minimum) mappings for:

A host name for the Check Point system.The serial number of the Check Point IP security platform.A static IP address for the platform.

IPSO also supports MAC-address based configuration.Beginning with Check Point IPSO 3.8, the DHCP client accepts the lease time for the IP address that the server provides. When the lease expires, the DHCP client contacts the server. Previously, the client accepted only IP address leases that were at least a year long.


Using DHCP to Configure the System

NoteYour DHCP server must be on the same network as the Check Point platform or the DHCP/BOOTP relay must be configured on the intermediate routers.

The following example shows relevant DHCP configuration information:ddns-update-style ad-hoc;subnet 10.1.1.0 netmask 255.255.255.0 {

# default gatewayoption routers 10.1.1.1;option subnet-mask 255.255.255.0;

option domain-name-servers 24.5.207.179;

range dynamic-bootp 10.1.1.20 10.1.1.100;

host IP710fixed {

# serial number of the boxoption dhcp-client-identifier "123456";

fixed-address 10.1.1.11;option host-name "IP710";

}

}



Running the DHCP Client on the Check Point System

NoteDo not perform the following procedures unless you configured an appropriate DHCP server with configuration information for your platform.

1. Connect a NIC installed in your platform to your network. 2. Turn the platform on.

The DHCP client program in the system starts automatically, and your DHCP server provides the appropriate configuration information. (This can require 5 to 10 minutes.)

3. From a computer on the same network, ping the IP address that you configured your DHCP server to provide to the Check Point system.When you receive replies from ping, you can use Check Point Network Voyager to connect to the system.

4. Connect to the system by using Voyager.To connect, start a Web browser and enter the IP address or host name of the system in the address or URL field of the browser.

5. Enter the user name admin and the password password.6. Modify the configuration of the system as appropriate.

NoteCheck Point strongly recommends that you change the password.

For information about how to proceed, see “Performing Additional Configuration” on page 139. If you intend to use the IPSO CLI or shell, be sure to see “Using the IPSO CLI” on page 139.


Using the Console to Configure the System

Using the Console to Configure the SystemIf you are installing a new Check Point IP security platform and are not using DHCP to perform the initial configuration, follow the instructions in this section to perform the initial configuration.Before you begin, make sure that you know:

A host name to assign to the platform.An IP address that you will assign to the platform.The appropriate network mask length.The IP address of the default gateway for the platform.An appropriate password to assign to the administrator account.

Performing the Configuration1. Establish a physical console connection to the Check Point IP security

platform. The console can be any standard VT100-compatible terminal or terminal emulator with the following properties:

RS-232 data terminal equipment (DTE) 9600 bps8 data bitsNo parity1 stop bit

You can also use a data communications equipment (DCE) device.To establish the physical console connection, follow these steps:a. Connect the appropriate cable to the local console port on the front

panel of the platform. If the console is DTE, use the supplied null-modem cable (console cable). If the console is DCE, use a straight-through cable.

b. Connect the other end of the cable to the console system.



2. Turn the platform on.After some miscellaneous output appears on the console connection, the following prompt appears:Hostname?

If the Hostname? prompt does not appear on the console, see the Installation Guide of the relevant IP appliance platformfor troubleshooting suggestions.

3. Respond to the Hostname? prompt within 30 seconds to prevent the DHCP client from starting.If you wait more than approximately 30 seconds before you type a response to the host name prompt, the DHCP client program starts automatically, and the system might be provided with a host name and IP address that is unknown to you. (This could happen if a DHCP server on your network is configured to supply configuration information to any system that requests it.)If this happens, follow these steps:a. Establish a console connection to the platform.b. Log into the system using the user name admin and the password

password.c. Enter:

rm /config/active

ormv /config/active /config/active.old

d. Reboot the platform.e. Respond to the configuration prompts in a timely manner.

4. Respond to the following prompts.


Using the Console to Configure the System

When you see the following message, type 1: You can configure your system in two ways:

1) configure an interface and use our Web-based Voyager via aremote browser

2) configure an interface by using the CLI

Please enter a choice [ 1-2, q ]:

5. You are prompted to select a network interface to configure: Select an interface from the following for configuration:

1) ser-s2p1

2) eth-s3p1

3) eth-s4p1

4) eth-s5p1

5) quit this menu

Enter choice [1-5]:

The list of interfaces that you see depends on the NICs that are installed. In the preceding example, ser-s2p1 is a serial interface in chassis slot 2, port 1, and eth-s3p1 is an ethernet interface in chassis slot 3, port 1. Type the number for the interface to configure. Remember that this is the interface you will connect to with Check Point Network Voyager or the CLI to continue with the configuration.

6. At the prompt, enter the IP address and subnetwork mask length.7. When you see the following message, choose y (the default option):

Do you wish to set the default route [ y ] ?

If you choose n, you cannot use Network Voyager unless you do one of the following:

Perform the installation procedure again and set a default route.



Use the command-line interface over a console connection to create a default route or static route.Connect to the platform by using a system that is on the same network as a configured interface on the platform.

8. If you have a modem installed, you see a message similar to the following: <PR20674>Modem detected on /dev/cuaa1.

Enable logins on this modem [y,n]:

To enable logging in to the platform through the modem, you can configure the modem now or you can configure it in Check Point Network Voyager or the IPSO CLI after you complete the installation. To configure the modem for logins now, type y. You are then prompted to configure a country code for the modem. For a list of the valid country codes, see “Modem Country Codes” on page 170.

9. When you are prompted to reboot the system, type: reboot

and press Enter.

Registering the IP ApplianceTo activate the IP Appliance, you must first register it. To register the appliance, you must provide its MAC address. The registration generates a Check Point license and shows you how to install it. Use either of the following methods:

Appliance registration wizard at http://register.checkpoint.com/cpapp Check Point User Center https://usercenter.checkpoint.com


http://register.checkpoint.com/cpapp

https://usercenter.checkpoint.com

Performing Additional Configuration

Performing Additional ConfigurationAfter you reboot the system, you are ready to continue configuring it. You can connect to the network interface you configured and perform the additional configuration using either:

Check Point Network VoyagerThe IPSO CLI

Using Check Point Network VoyagerTo log in to the system by using Network Voyager, follow these steps:1. Start a Web browser on a workstation that has network connectivity to the

Check Point IP security platform.2. In the Location or Address field of the browser, enter the IP address of the

interface you configured on the platform.3. Enter the user name admin and the password you entered when you

performed the initial configuration in the appropriate fields.

Using the IPSO CLIAfter the system reboots, SSH is on by default as a security measure. This means that you have two options to connect to a network interface and use the IPSO CLI (or the IPSO shell):

Use an SSH client. This is the recommended approach. For more information, see “Using an SSH Client.” If you do not want users to be able to access the system with an SSH client, see “Disabling SSH” on page 142 for information about how to disable SSH.Connect to the configured network interface by using Telnet if it is enabled. Telnet is disabled by default if you:

purchase a platform with IPSO 4.2 installed



perform a fresh installation of IPSO 4.2 (use the boot manager install command)load a factory default configuration database

To maintain optimum security, Check Point recommends that you disable Telnet and use an SSH client. For more information about how to disable Telnet, see “Disabling Telnet” on page 141.

NoteSSH does not apply to console connections. Regardless of whether SSH is enabled, you can always access the Check Point IP security platform over a console connection.

Using an SSH ClientTo communicate with your Check Point system by using SSH, you must have an SSH client program installed on a workstation that has network connectivity to the Check Point IP security platform. You can get information about SSH client programs at http://www.freessh.org.At a minimum, you should use a host key as explained in “Using a Host Key.” For even better security, use authorized keys as well. For more information about how to use SSH with your Check Point system, see the Check Point Network Voyager Reference Guide (available on the Check Point Security Platform Software CD that came with your platform or from the Check Point Network Voyager navigation tree by selecting Documentation > IPSO Documentation.)

Using a Host Key

IPSO automatically generates a host public and private key pair after you perform the initial configuration. For maximum security, you can install the public part of this key on the workstations that you will use to connect to the Check Point system. Having the host public key installed allows the SSH client program to verify that it really is communicating with the Check Point


http://www.freessh.org


system and not a system that is falsely purporting to be the Check Point system.If you do install the host public key on workstations, the most secure way to transport the key is to use an out-of-band method, such as transporting the key on a floppy disk. This reduces the possibility that the key could be stolen in transit.If you do not install the public host key on a workstation that you use to connect to the platform, the Check Point system asks the SSH client to accept the key the first time you attempt to connect:

If you choose to accept the key, the connection is established. This procedure is potentially less secure because the SSH client cannot be sure that the host key is really being supplied by the Check Point system.If you choose to not accept the key, you are not able to connect to the Check Point system.

When a workstation has the host public key (regardless of how it received it), the SSH client program can connect to the Check Point system as long as the host public and private key pair is valid.

Disabling TelnetYou can use Check Point Network Voyager or the IPSO CLI to disable Telnet.

NoteYou must have Telnet enabled on your Check Point IP security platforms platforms for Check Point Horizon Manager to communicate with the platforms in the unsecure mode. See the Horizon Manager documentation for more information.

To use Check Point Network Voyager to disable Telnet1. Log into the platform by using Check Point Network Voyager.

Enter the user name admin and the password you configured for this user when you performed the initial configuration.

2. In the Network Voyager navigation tree, select Configuration > Security and Access > Network Access and Services.



3. Click No for the Allow TELNET Access field.4. Click Apply. 5. Click Save to make your change persistent across reboots.

To use the CLI to disable Telnet1. Establish a console connection to the platform.2. Log in using the user name admin and the password you configured for

this user when you performed the initial configuration.3. Start the CLI by entering:

clish

4. Enter:set net-access telnet no

Disabling SSHYou can use Check Point Network Voyager or the IPSO CLI to disable SSH.

NoteSSH must be enabled on your Check Point IP security platforms for Horizon Manager to communicate with the Check Point platforms in the secure mode. For more information, see the Check Point Horizon Manager documentation

To use Check Point Network Voyager to disable SSH1. Log in to the platform by using Network Voyager.

Enter the user name admin and the password you configured for this user when you performed the initial configuration.

2. In the Network Voyager navigation tree, select Configuration > Security and Access > SSH (Secure Shell) > SSH Configuration.

3. Click No for Enable SSH service (daemon sshd).



4. Click Apply. 5. Click Save to make your change persistent across reboots.

To use the IPSO CLI to disable SSH1. Establish a console connection to the platform.2. Log in by using the user name admin and the password you configured

for this user when you performed the initial configuration.3. Start the CLI by entering:

clish

4. Enter:set ssh server enable off




4 Upgrading to Check Point IPSO 4.2

You can upgrade directly to Check Point IPSO 4.2 from the following IPSO versions:

3.73.7.13.83.8.13.94.04.0.14.1

NoteIf you want to fresh install IPSO 4.2 on a platform running IPSO 6.x, follow the instructions in the Getting Started Guide and Release Notes for IPSO 6.1 MR2 (Build 38a03)http://downloads.checkpoint.com/dc/download.htm?ID=10251(See “Installing IPSO 4.x” in the chapter “Upgrading to Check Point IPSO 6.1.”) Do not use the instructions in the 4.2 release notes.

CautionAvoid using the IPSO boot manager to install IPSO 4.2 on a platform running IPSO 4.1 Build 016 or 019 if you installed the 4.1 build using


http://downloads.checkpoint.com/dc/download.htm?ID=10251


the boot manager. If you attempt to upgrade in this way, the system might repeatedly panic and reboot. To upgrade these systems to IPSO 4.2, use Network Voyager, the CLI, or the newimage shell command. <PR 56221>

CautionIf you upgrade to IPSO 4.2 from IPSO 3.7, IPSO 3.7.1, or earlier and want to use disk mirroring, you must first install the 4.2 boot manager and then install IPSO 4.2 from the new boot manager. If you do not, you might receive messages that show that the mirror set is 100 percent complete or that the “sync process” is complete when in fact the disks are still syncing. You do not need to follow this procedure if you upgrade to IPSO 4.2 from IPSO 3.8, 3.8.1, 3.9, 4.0, 4.0.1, or 4.1.

NoteIf you use Check Point Horizon Manager to manage your platforms, you can upgrade and revert to earlier versions of IPSO on all of your platforms simultaneously or in groups of multiple platforms. Horizon Manager employs Do No Harm intelligence to prevent incompatible package installations on Check Point platforms.

You can obtain IPSO 4.2 by downloading the software from the Check Point support site at http://support.checkpoint.com. You can install IPSO and packages by using the following:

Check Point Horizon Manager (on multiple Check Point platforms simultaneously)Check Point Network Voyager (on one Check Point platform at a time)IPSO CLIIPSO command shell (console session)

You can also install IPSO and packages on multiple cluster nodes simultaneously by using Cluster Voyager or the Cluster CLI. For more information, see the Clustering Configuration Guide for Check Point IPSO



Downloading Check Point IPSO and Related Files

6.2 http://supportcontent.checkpoint.com/documentation_download?ID=10294

Downloading Check Point IPSO and Related Files

To download IPSO and related files and documentation: 1. Log on to the Check Point Support site at http://support.checkpoint.com,

using your Check Point User Center Account. 2. On the Support page, Search for "IPSO 4.2". 3. Click the Downloads tab. 4. In the Download Results, click the link to the IPSO 4.2 build 111

download page. 5. In the Download page, note the MD5 value for verifying file integrity

before installation.6. Click Download.7. Download the appropriate zip file to an FTP server or workstation. 8. Unzip the zip file to get ipso.tgz and other files. The IPSO 4.2 build 111 download package contains the IPSO 4.2 installable image (ipso.tgz) and the IPSO 4.2 Boot Manager file.You can now install IPSO 4.2 remotely from the FTP server or workstation. (See “Installing Check Point IPSO 4.2 from Check Point Network Voyager or the Command Shell” on page 151.)


https://support.checkpoint.com

https://support.checkpoint.com

http://support.checkpoint.com




Using Check Point Horizon Manager to Install IPSO and Packages

You can use Check Point Horizon Manager to automate the process of installing, upgrading, and enabling IPSO 4.2 and software packages on multiple Check Point platforms. Horizon Manager employs Do No Harm intelligence to prevent any incompatible IPSO version upgrades. Use the OS Install action to install IPSO 4.2 on as many as 2500 platforms in a single data set. Horizon Manager also provides actions that automate the installation and upgrade of software packages, such as Check Point NGX and associated feature packs. Horizon Manager automates the entire installation process, including backing up configuration information before the upgrade and rebooting platforms to activate the new version of IPSO.If you are using Horizon Manager to automate the process of installing or upgrading IPSO or software packages, you might not need to use this document further.For detailed information about the installation and upgrade process, see the Horizon Manager documentation.http://downloads.checkpoint.com/dc/download.htm?ID=9889

Before You Install Check Point IPSO from Check Point Network Voyager or the Command Shell

You need at least 140 MB of free disk space in your root partition to install an IPSO 4.2 image. To determine the available disk space, log in to the IPSO shell through a terminal or console connection and enter df -k. If the first number in the Avail column (which shows the available space in the root partition) is less than 140000 Kbytes, you should make more space available in the root partition by deleting the temporary files specified in the following command if they are present. (These files might not be present, depending on


Before You Install Check Point IPSO from Check Point Network Voyager or the Command Shell

how the upgrades were done on your system.) Execute the following commands to delete the list of unwanted files:mount -uw /rm -f /image/*/bootmgr/*.savrm -f /image/*/bootmgr/*.tmpsyncmount -ur /

If you use the df command after you install IPSO 4.2 as a third image, you might see that the root partition is more than 100 percent full. If no errors were displayed while you installed IPSO 4.2, you can safely ignore this output from df.When you have enough space in the root partition, follow the instructions in “Putting the ipso.tgz file on the Platform.”

Putting the ipso.tgz file on the PlatformAfter you make sure that at least 140000 Kbytes are available on the root partition, put the ipso.tgz file on an FTP server and transfer this file to the platform. You can transfer the ipso.tgz in either one of the following two ways:

FTP the ipso.tgz file to the platform and install IPSO in one procedure. Follow the appropriate instructions in “Installing Check Point IPSO 4.2 from Check Point Network Voyager or the Command Shell” on page 151.FTP the ipso.tgz file to the platform first and then install IPSO in a separate procedure.Follow the instructions in “Transferring the ipso.tgz file” and “Verifying SHA1 Values” on page 151 and then follow the appropriate instructions under “Installing Check Point IPSO 4.2 from Check Point Network Voyager or the Command Shell” on page 151.



CautionIf you perform a fresh installation of IPSO, you must download the ipso.tgz file and perform the installation at one time. Do not copy the ipso.tgz file to the platform first—it will be overwritten during the installation procedure. For more information, see “Overwriting Existing Images (Fresh Installation)” on page 157.

Transferring the ipso.tgz fileTransferring IPSO 4.2 to your platform as a separate step allows you to perform a local installation (as opposed to a remote installation from an FTP server). 1. Use Check Point Network Voyager to enable FTP access to the platform.

To do so, select the Network Access and Services link under Security and Access. Then:a. In the Allow FTP access field, click Yes. b. Click Applyc. Click Save to make your change permanent.

2. To copy IPSO 4.2 from a workstation:a. Insert the CD-ROM into the CD drive of the workstation.b. Make sure that you can connect to the Check Point platform over the

network. 3. Open the directory on the FTP server or workstation that contains the

ipso.tgz file (this can be the image directory on an IPSO CD-ROM). 4. Begin an FTP session to your platform.

By default, the current directory should be var/emhome/admin. Do not change the current directory.

5. At the prompt, enter: bin


Installing Check Point IPSO 4.2 from Check Point Network Voyager or the Command Shell

6. Transfer the ipso.tgz file to the platform. At the prompt, enter:put ipso.tgz

7. Close the FTP session.

Verifying SHA1 ValuesUse the SHA1 application to verify that the ipso.tgz file did not change during the download process: 1. Log on to the platform through a console connection.2. At the prompt, enter:

openssl sha1 ipso.tgz

You should see a response that displays the same SHA1 value that matches the SHA1 value shown at the Check Point support site. For example, you should see something like the following (this is an example only; you might see a different value):SHA1 (ipso.tgz) = 6E6CF1281DCCD41EE49E77CE4F1AB537E30E66C0

3. Compare the SHA1 value you see to the value posted on the Check Point support site. If the values are identical, the download was successful and the file is good. If not, download the file (in binary) again and repeat this procedure.

To complete your installation of IPSO, proceed to the following section.


You can change the version of IPSO running on your platform in either of the following ways:

Add the new version of IPSO (also known as an IPSO image) without removing the existing images or your configuration information. If you



add a new version, you can revert to the earlier versions stored on the platform. When you do so, your configuration information is not affected. If you copied the ipso.tgz file to the platform you are upgrading as described in “Transferring the ipso.tgz file” on page 150, you must use this method. You can use Check Point Network Voyager, the IPSO shell, or the IPSO CLI to add an image. The procedures for using Network Voyager and the IPSO shell are explained below. For information about how to add an image using the IPSO CLI, see the CLI Reference Guide for Check Point IPSO 6.2 http://downloads.checkpoint.com/dc/download.htm?ID=9862.When you add an IPSO image, the IPSO boot manager is upgraded automatically if your system does not have the boot manger for the image you are adding.

NoteOn flash-based platforms, you can have a maximum of two IPSO images installed at a time. If needed, delete older IPSO images before you add IPSO 4.2.

When you delete a previous system image on an IP265 to make room for a new system image, wait a few minutes after deleting the previous image before you install the new one. The IP265 requires a couple of minutes to delete the previous image, and if you try to install a new image before it completes deleting the old one, you will receive a message saying there is insufficient space for the new image. <PR 56716>

Perform a fresh installation, which removes the existing images and your configuration information. If you perform a fresh installation, you can restore versions of IPSO that were previously installed, but the process is more involved and all of your configuration information is removed again.For information about how to perform a fresh installation, “Overwriting Existing Images (Fresh Installation)” on page 157.




When you perform a fresh installation, you are asked whether you want to upgrade the boot manager program, if this is appropriate. You should choose to upgrade the boot manager.

NoteThe installation process takes longer on flash-based systems than on comparable disk-based systems. For example, if you install an image (using either of the above methods) on a flash-based IP1260 and a disk-based IP1260, the installation time is noticeably longer on the flash-based system. This is expected and does not indicate any problem.

Changes to User AccountsWhen you upgrade to IPSO 4.2 from a release previous to IPSO 4.0, the following changes are made to the existing user accounts.

Users with a UID of 0 are assigned the adminRole. This role cannot be changed for these users. Any user with a UID other than 0 is assigned the monitorRole. This role provides read-only access to every feature on the system. You can change the access rights by creating new roles and assigning these roles to users.Any users with a UID of less than 102 are automatically assigned a unique UID greater than 102. UIDs up to 102 are reserved for system use.If you have clustering enabled, the cadmin user’s UID is changed from 0 to 101 and the clusterAdminRole is assigned. The cluster domain is also assigned; the domain is the cluster ID.All user home directories are re-created in the /var/emhome directory. For example, the home directory for the admin user is now in/var/emhome/admin. If you need to fall back, the existing home directories are left intact.



NoteIf your system uses scripts that reference the /var/admin directory, change the script to instead reference ~admin or /var/emhome/admin. You must do this if your system is flash-based (diskless). It is recommended that you do this for disk-based systems as well, although, in this case, the script will not break because the existing home directories are left intact.

For information about configuring role-based administration, see the Check Point Network Voyager Reference Guide for IPSO 6.2http://supportcontent.checkpoint.com/documentation_download?ID=10293

Adding a Check Point IPSO Image Using VoyagerUsing Network Voyager is a convenient way to add an IPSO image to a platform. For instructions about how to do this, refer to the “Configuring System Functions” of the Check Point Network Voyager Reference Guide.If the documentation package has been installed on your platform, the Check Point Network Voyager Reference Guide is available from Network Voyager. For IPSO releases previous to IPSO 4.0, you access the guide by clicking the Doc button. For IPSO 4.0 and later, you access the guide from the IPSO Documentation link in the Network Voyager navigation tree.

Adding a Check Point IPSO Image from the Command Shell

This section describes how to install IPSO by using the IPSO command shell over a console connection. For instructions about how to install IPSO by using the CLI, see the “System Configuration Commands” section of the CLI Reference Guide for Check Point IPSO 4.2. You can get the CLI Reference Guide from Network Voyager, if the IPSO documentation package is installed. Alternatively, see the IPSO




6.2 CLI guide athttp://downloads.checkpoint.com/dc/download.htm?ID=10295

NoteWhen you add an image or perform a fresh installation by using the IPSO command shell, use a console connection (rather than by Telneting to an interface that is already configured).

To add a new image from the IPSO command shell, use the newimage command. The syntax is:newimage [[-i | -l local_file] [-b] [-R | -T]] [-r | -t image_name] [-k] [-v]

Table 9 describes the options you can use with the newimage command.

Table 9 newimage Options

-i Load a new image interactively. Interactive mode supports anonymous FTP, FTP with a user name and password, and access to the local file system. If you use this option, do not choose to install from a CD-ROM if your system does not have a CD-ROM drive. <PR 52870>

-l local_file Extract the new image from a local file.

-b Force upgrade of boot manager.

-R Use newly installed image at next reboot.

-T Test boot using newly installed image .

-r image_name Specify image to run at next boot.

-t image_name Specify image to run at next test boot.




NoteYou must reboot your platform after you use the newimage command to upgrade the IPSO image. Save your current configuration before you install the new image.

To add an IPSO image1. Log on to your platform by using a console connection.

NoteIf you originally downloaded IPSO 4.2, use the SHA1 application to check that the file originated at Check Point and did not change during the download process. (See “Verifying SHA1 Values” on page 151.)

2. Perform one of the following, depending on whether you copied the ipso.tgz file to your platform or will install it from an FTP server:

If the IPSO image is copied to your platform, enter:newimage -k -l ipso.tgz

You should see a response similar to the following:ipso.tgz Validating image...done.

Version tag stored in image: IPSO-4.2-BUILD029-releng-1515-01.05.2007-222742

Installing new image...done [example]

If the IPSO image is on an FTP server, enter: newimage -i -k

-k Specify that any installed packages should be kept.

-v Verbose.



The installation procedures prompt you for the IP address of the FTP server and the path to the ipso.tgz file.

NoteOn some appliances, installing the image can take some time. The newimage program might display the message “Setting up new image...” for several minutes with no other sign of activity.

3. At the prompt, choose the image to load after the next reboot.4. At the prompt, reboot your platform.

Overwriting Existing Images (Fresh Installation)

CautionThe following procedure deletes any existing images and configuration information on your platform. Back up any files that you want to keep and copy them back to the platform after you install the new system.

Before you begin, make sure that you know: The serial number of your platform. The number is on a sticker attached to the platform and is preceded by “S/N.”Whether the platform will run IGRP.Whether the platform will run BGP.Whether to run the platform in flash-based (diskless) mode. For disk based platforms, enter n, for no when you are prompted after the following question: Do you want to install a diskless image (y/n)?



NoteIf there is a flash-memory PC card installed in a flash-based platform, the installation script also asks you whether you want to install the image or store log files on the card. You should not install an image on a PC flash card. If possible, you should not store log files on the card either. The best way to store logs locally on a flash-based platform is to use a hard disk installed as an optional disk.

An IP address that you will assign to the platform.The appropriate network mask length.The IP address of the FTP server.The path to the ipso.tgz file on the FTP server.The IP address of the default gateway for the platform.A host name to assign to the platform.An appropriate password to assign to the administrator account.The boot manager password (if any). If you need information about this password, see the Check Point IPSO Boot Manager Reference Guide http://supportcontent.checkpoint.com/documentation_download?ID=10297

NoteIf you perform a fresh installation and later downgrade to an earlier version of Check Point IPSO, all current configuration information except basic connectivity information is deleted. For example, if you perform a fresh installation of IPSO 4.2 and later downgrade to IPSO 3.9, everything except your connectivity configuration is deleted after you reboot your platform. If you downgrade to a version of IPSO previous to 3.6, your connectivity information is also deleted.

The following sections describe a fresh installation of the IPSO image using the install command. The procedure differs depending on your platform. To perform a fresh installation on a platform, see “Performing a Fresh Installation” on page 159.


� http://supportcontent.checkpoint.com/documentation_download?ID=10297


Performing a Fresh Installation1. Log on to your platform through a console connection. 2. At the prompt, enter: reboot.3. If you see the following message, Press 1:

Verifying DMI Pool Data ........ 1 . . . Bootmgr

2 . . . IPSO

Press 1 to start the boot manager.

4. When the system enters autoboot mode and displays following the message, press any key to display the boot manager prompt:Type any character to enter command mode

5. At the boot manager prompt, enter: install.If a password is configured, the system prompts you to enter the boot manager password.The installation script runs. Follow the prompts to install the new IPSO image from an FTP server.

6. If you are asked whether you want to upgrade the boot manager, choose to do so.

7. At the end of the installation procedure, press Enter when you see this prompt:Installation completed.

Reset system or hit <Enter> to reboot.

8. After your platform reboots, follow the prompts to configure basic settings such as hostname and admin password.



9. When you see the following message, type 1:You can configure your system in two ways:

1) configure an interface and use our Web-based Voyager via aremote browser

2) configure an interface by using the CLI

Please enter a choice [ 1-2, q ]:

10. Configure the appliance interface by responding to the prompts. When you see the following message, choose y (the default option):

Do you wish to set the default route [ y ] ?

If you choose n, you cannot use Network Voyager unless you do one of the following:

Perform the installation procedure again and set a default route.Use the command-line interface over a console connection to create a default route or static route.Connect to the platform by using a system that is on the same network as a configured interface on the platform.

11. If you have a modem installed, you see a message similar to the following: <PR20674>

Modem detected on /dev/cuaa1.

Enable logins on this modem [y,n]:

To enable logging in to the platform through the modem, you can configure the modem now or configure it in Network Voyager or the IPSO CLI after you complete the installation. To configure the modem for logins now, type y. You are then prompted to configure a country code for the modem. For a list of the valid country codes, see “Modem Country Codes” on page 170.

12. When you are prompted to log in to the platform, you are ready to continue configuring your platform. Do one of the following:


Installing and Activating Packages

Log into the platform and use the newpkg command to install packages. For more information, see “Using the newpkg Command” on page 165.Use Check Point Network Voyager to complete the configuration (including installing packages). To log in by using Network Voyager, enter the IP address you configured for the platform in the URL field of your browser.

Installing and Activating PackagesAfter you install Check Point IPSO, you might want to install Check Point documentation and third-party packages (Check Point VPN-1 NGX, for example). If you added a new version of IPSO by using the newimage command and the -k (keep) option, your previous packages are active with the new IPSO version. If you used newimage without -k option, all the optional packages currently installed on the platform are turned off, but they are not deleted. To turn these packages on again, see “Activating Packages” on page 164.

NoteCheck Point recommends that you install the latest documentation package whenever you upgrade IPSO.

If you performed a fresh installation of IPSO, you must install and activate the packages you want to use. You can do this by using Check Point Horizon Manager, Check Point Network Voyager, the command-line interface (CLI), or the newpkg command at the IPSO command shell.

NoteThe installation process takes longer on flash-based systems than on comparable disk-based systems. For example, if you install a package on a flash-based IP1260 and a disk-based IP1260, the installation time is



noticeably longer on the flash-based system. This is expected and does not indicate any problem.

You can download, install, or activate packages by using Horizon Manager on all of your Check Point platforms simultaneously or on groups of multiple devices simultaneously. Horizon Manager employs Do No Harm intelligence to prevent the installation of incompatible packages on Check Point platforms.For information about how to use the CLI to install and activate packages, see the CLI Reference Guide for Check Point IPSO 4.2. You can get the CLI Reference Guide from Network Voyager, if the IPSO documentation package is installed. Alternatively, see the IPSO 6.2 CLI guide at http://supportcontent.checkpoint.com/documentation_download?ID=10295For information about using Horizon Manager to install and activate packages, see the Horizon Manager User’s Guidehttp://downloads.checkpoint.com/dc/download.htm?ID=9889For information about the newpkg command, see “Using the newpkg Command” on page 165. For information about how to install packages, see “Using Check Point Network Voyager to Install Packages” on page 162.

Using Check Point Network Voyager to Install Packages

To install Check Point documentation and release packages by using Network Voyager:1. Log on to your platform by using Check Point Network Voyager.2. In the Network Voyager navigation tree, select Configuration > System

Configuration > Packages > Install Package.3. Enter the name or IP address of the FTP server.4. Enter the path to the directory on the FTP server where the packages are

stored.





5. If necessary, enter the appropriate user name and password.6. Click Apply.

The names of the available packages appear in the Site Listing window.7. Select the package you want to install.8. Click Apply.

The selected package is downloaded to the platform. When the download is complete, the package appears in the Unpack New Packages field.

9. Select the package in the Select a package to unpack field.10. Click Apply.11. Click the link to install or upgrade the package.12. (Optional) To display all installed packages, click Yes next to Display all

packages; then click Apply.13. (Optional) To perform a first-time installation, click Yes next to Install;

then click Apply.14. (Optional) To upgrade a package, click Yes next to Upgrade.15. (Optional) To upgrade a package, click the button of the package that you

want to upgrade under Choose one of the following packages to upgrade from.

16. Click Apply.17. Click Save to make your changes permanent.The packages are automatically activated as part of the installation process. To confirm the package installation and activation, check the Manage Packages page. If a package has not been activated, you can activate as described in “Activating Packages.”

CautionWhen you install a package using Voyager, you see the following message:

Voyager environment has been updated with the latest



package info.The telnet session environment will be updated by:logging out and logging in again the telnet session.

This message might not be accurate. Click Manage Packages to verify that the package is installed. Refresh the page periodically until you see that the installation is complete. <PR 44880>

NoteWhen the IPSO documentation package is activated, a link to the documentation is placed in the Network Voyager navigation tree. If you do not see that link after package installation or if the link takes you a previous version of the IPSO documentation, refresh your browser.

Activating Packages To turn on optional packages that were deactivated when you added a new version of Check Point IPSO by using the newimage command:1. Log on to the platform using Check Point Network Voyager.2. In the Network Voyager navigation tree, select Configuration > System

Configuration > Packages > Manage Packages.3. Click On next to the packages you want to turn on.4. Click Apply.5. Click Save. 6. Reboot your platform.Your installation of IPSO 4.2 is complete, and the packages that you selected are activated.



Using the newpkg CommandUse the newpkg command to add or upgrade documentation and third-party packages. The syntax of newpkg is:newpkg [-d] [-h] [i] [-l user_name] [-m media_type] [-n path] [-o path] [-p password] [-s server_ipaddrs] [-S] [-v]

Table 10 describes the options you can use with the newpkg command.



Table 10 newpkg Options

NoteThe newpkg command is automatically invoked if you perform a fresh installation. You are prompted to install or skip each package.

To turn on the installed packages, continue with the procedure in “Activating Packages” on page 164.

-d Print debug messages.

-h Display help lines for command-line parameters.

-i Install only (do not activate).

-l user_name User name for FTP.

-m media_type Media type; for example, FTP, CD, and so on.

-n path Full path to new package.

-o path Full path to old package for upgrade.

-p password Password for FTP.

-s server_ipaddrs The server IP address if media type is FTP/AFTP.

-S Silent mode. Silent mode requires the following options: -o, -m, -n. If the media type is FTP/AFTP, silent mode also requires -s. If the media type is FTP, silent mode also requires -l, -p.

-v Verbose FTP.



Installing R65 HFA 70 on Disk-Based Platforms

NoteBefore installing R65 HFA 70, refer to the release notes at http://supportcontent.checkpoint.com/documentation_download?ID=10703

NoteYou must follow these steps precisely to avoid installation problems.

To install R65 HFA 70 on disk-based IPSO:1. Create a temporary directory on /opt:

mkdir /opt/hfa 2. Navigate to the new directory:

cd /opt/hfa

3. Verify that there is enough free disk space for the installation of the HFA packages.

4. Download the package Check_Point_NGX_R65_HFA_70.ipso.tgz for IPSO 4.2 disk-based platforms from http://supportcontent.checkpoint.com/file_download?id=10682to /opt/hfa.

5. Extract the contents.6. Execute:

./UnixInstallScript and follow the on-screen instructions.

7. Reboot the machine.


http://supportcontent.checkpoint.com/file_download?id=10682



Installing R65 HFA 70 on Flash-Based Platforms

Note1. Before installing R65 HFA 70, refer to the release notes at http://supportcontent.checkpoint.com/documentation_download?ID=10703

2. Uninstallation of R65 HFA 70 from flash-based IP appliances is not supported.

3. You must follow these steps precisely to avoid installation problems.

4. Only the administrator running the installation process can be logged into the server during the installation. No other console or SSH session can be open during the installation.

Before installing R65 HFA 70 on a Flash-Based Appliance:

1. Make sure that the R65 Firewall and CPInfo packages are the only packages stored on the server. All other Check Point packages must be deleted. You can do this using Network Voyager or using the command shell.Using Network Voyager:a. Choose Configuration > System Configuration > Packages > Delete

Packages.b. Select a previous installation package to delete, and click Apply.c. Delete any tgz files.d. Click Apply.Using the command shell, run:newpkg -qnewpkg –u <previous package name>rm opt/packages/<previous tgz name>




2. If there is an IPSO image that is not in use on the machine, delete it using Network Voyager:a. Choose Configuration > System Configuration > images > Manage

Images.b. Click Delete IPSO Images.c. Select the IPSO image to delete, and click Apply.

3. Delete any core file on the system. Run savecore -c or savecore -r

4. Verify that there is enough free disk space for the installation of the packages:

For /preserve, you need at least 455000 KB free.(To find absolute free space: run the df -k /preserve command and subtract the 3rd column Used from the 2nd column 1K-blocks).For /opt and /var, you need at least 382000 KB free.

To install R65 HFA 70 on a Flash-based Appliance:

1. Run: cpstop2. If using 1GB RAM systems, run the following command to extend the

/opt RAM disk partition: /sbin/mount -u -o extend_partition /dev/null /opt

To verify that the /opt partition was extended to at least 500000 KB, run the df command.

3. Create a temporary directory on /opt: mkdir /opt/hfa

4. Navigate to the home directory: cd ~

5. Download Check_Point_NGX_R65_HFA_70.ipso_Flash.tgz, the HFA file for IPSO 4.x to the home directory: http://supportcontent.checkpoint.com/file_download?id=10683


http://supportcontent.checkpoint.com/file_download?id=10683


6. Extract the contents to /opt/hfa: tar –zxvf Check_Point_NGX_R65_HFA_70.ipso_Flash.tgz -C /opt/hfa

7. Delete the *.tgz file to save flash disk space.8. Navigate to the /opt directory:

cd /opt

9. Move the hfa directory to admin: mv /opt/hfa /var/emhome/admin/

10. Navigate to the /var/emhome/admin/hfa directory: cd /var/emhome/admin/hfa

11. Install the HFA: ./UnixInstallScript

12. Reboot the machine.13. After reboot, remove the hfa directory:

rm -rf /var/emhome/admin/hfa

Modem Country CodesIf you configure a Check Point-supported PC card modem while you are installing Check Point IPSO, use the tables in this section to choose the appropriate country code.

Table 11 Country Codes for Ositech Five of Clubs Modem

Country Code Country

22 USA

20 Canada

1 Australia

2 Belgium

3 Denmark

4 Finland


Modem Country Codes

Table 12 Country Codes for Ositech Five of Clubs II Modem

5 France

6 Germany

17 Greece

99 Iceland

7 Ireland

8 Italy

9 Luxembourg

10 The Netherlands

11 Norway

12 Portugal

13 Spain

14 Sweden

25 Switzerland

16 United Kingdom


B5 USA

20 Canada

09 Australia

0F Belgium

31 Denmark

3C Finland

3D France

42 Germany

46 Greece

57 Iceland




59 Italy

69 Luxembourg

7B The Netherlands

82 Norway

B8 Portugal

A0 Spain

A5 Sweden

A6 Switzerland

B4 United Kingdom



5 Supported Platforms, Versions and Memory Configurations

This chapter contains information on the following topics:Supported PlatformsSupported Check Point VersionsSupported Memory Configurations <PRs 45068, 45119, 48954>



Supported PlatformsYou can run IPSO 4.2 and an application on the following Check Point IP security platforms:

IP130 (NGX R65 not supported)IP150IP260IP265 (NGX R65 not supported)IP282IP290 (disk-based and flash-based)IP350IP355IP380IP385IP390 (disk-based and flash-based)IP530 (NGX R65 not supported)IP560 (disk-based and flash-based)IP690 (disk-based and flash-based)IP710IP740IP1220 (disk-based and flash-based)IP1260 (disk-based and flash-based)IP1280 (disk-based and flash-based)IP2250IP2255IP2450

For better performance, Check Point recommends that you have at least 256 MB of memory in your platform.


Supported Check Point Versions

Supported Check Point VersionsThe Check Point IPSO 4.2 operating system supports Check Point NGX R60, R61, R62 and R65 on Check Point IP security platforms. IPSO 4.2 Build 051 and later, in combination with NGX R65, supports anti-virus and web filtering. The features and operation of this application is described in separate documents.NGX R65 is not supported on the following platforms:

IP130IP265IP530

For information on upgrading Check Point NGX, see “Installing and Activating Packages” on page 161.

Supported Memory Configurations <PRs 45068, 45119, 48954>

When running SecureXL on a Check Point appliance, for a given amount of memory, the appliance supports fewer connections when SecureXL is enabled than when it is running firewall flows, that is when SecureXL is not enabled. Generally, when SecureXL is enabled, one connection is the equivalent of two flows; when SecureXL is disabled, two flows are created for TCP connections. For unidirectional UDP traffic, one flow is created. However, if there is corresponding UDP traffic in the other direction, another flow is created; thus, the net effect in this case is that two flows are created for the UDP traffic.For information about how to configure the memory settings in Check Point’s Smart Dashboard, consult Table 13 and Table 14. The values in the tables assume that you use SecureXL. If you do not use SecureXL (and do use firewall flows instead), IPSO supports roughly twice the number of connections listed. A platform does not create more connections than its memory supports (even if you enter a value greater than the appropriate one listed here).



NoteYou must use SecureXL with the IP2250 and IP2255.

If you have a two-node IP cluster, make sure that Check Point’s Automatic Capacity Optimization feature is set to manual and use the appropriate memory settings listed in the tables. For clusters with more than two nodes, follow this procedure to determine the settings:1. Look up the maximum number of connections for a stand-alone platform

with the same amount of DRAM as the cluster node with the least amount of memory.

2. Divide that value by the number of nodes. Use the result as the maximum connections setting for all the nodes.

3. To configure the other memory settings, identify the maximum connections value in the appropriate table that is closest to the value you determined in step 2 and use the corresponding settings on all the nodes.

Table 13 Firewall Memory Settings for Disk-Based IP Security Platforms

DRAM

Maximum connections(stand-alone, VRRP)

Maximum connections(2-node IP cluster)

Maximum connections with Web Intelligence

Hash table size

Memory pool size

Maximum memory pool size

256 MB 36,000 2 MB 48 MB 64 MB

512 MB 135,000 67,000 50,000 4 MB 196 MB 256 MB

1 GB 360,000 180,000 140,00 8 MB 400 MB 512 MB

2 GB 725,000 362,000 325,000 16 MB 800 MB 900 MB


Table 14 Firewall Memory Settings for Flash-Based IP Security Platforms

DRAM

Maximum connections(stand-alone, VRRP)

Maximum connections(2-node IP cluster)

Hash table size

Memory pool size

Maximum memory pool size

512 MB 90,000 45,000 4 MB 128 MB 196 MB

1 GB 225,000 112,000 8 MB 256 MB 400 MB

2 GB 725,000 362,000 16 MB 800 MB 900 MB




6 Resolved Issues, Known Limitations and Configuration Tips

This chapter contains the following sections:Resolved Issues in IPSO 4.2 MR9Known Limitations and Configuration Tips

To see the most current list of limitations, see this document on the Check Point Support site at.http://supportcontent.checkpoint.com/documentation_download?ID=11191 Check Point wants to hear about information you might have regarding the limitations in this chapter. For information about how to contact Check Point Customer Service, see the contact information at the beginning of this document.The numbers associated with each known limitation or resolved issue (either starting with 00 or in angle brackets after each heading) is the tracking number for the issue in Check Point’s internal database. Refer to this number if you contact Check Point about an item in this chapter.




Resolved Issues in IPSO 4.2 MR9This section includes information about limitations that existed in previous versions, that have been fixed in IPSO 4.2 MR9.

ID Symptoms

00493141 When installing a policy on a gateway on which SecureXL is enabled, connections through the VPN tunnel are now properly maintained.

00552936 An ICMP unreachable message is now sent when SecureXL enabled.

00257338 OpenSSL was updated to protect against CVE-2009-3555.

00256616 The one Gigabit XMC Ethernet card now supports link recognition delay.

00258033 Improved handling of active FTP connections with Policy Based Routing (PBR).

00257186 NTP was updated to protect against CVE-2009-3563.

00256143 The system behaves properly when LAG and VRRP with vmac=interface is configured on IP390 on-board NIC.

00257200 Overlapping NAT is now supported on IPSO 4.2, when SecureXL is disabled. By default this feature is turned off. The command ispctl -a net:ip:fw:overlap_nat, will return the value is 0. To enable it, run ipsctl -w net:ip:fw:overlap_nat 1

00493302 IPSRD cpu spikes to 100 % whenever snmp queries for the VRRP mib are handled when there are a lot of vlans. The spike is caused by unnecessary ipsctl queries to the kernel to get the logical name of the interface. The kernel now generates an event whenever the logical name changes and this is used by IPSRD.


Resolved Issues in IPSO 4.2 MR9

00256299 IP560 no longer crashes when disabling autoadvertising on interface

00257950 IPSO 4.2 Build 105 introduced the feature to Disable/Enable All VRRP Virtual Routers. The option did not appear in Voyager's Legacy VRRP Configuration page. Now when a VR with Legacy VRRP Configuration is created, it is possible to Disable/Enable All VRRP Virtual Routers from Voyager.

00255889 Access Control Lists (ACLs) on Accelerated Data Path (ADP) interfaces can be configured to do Policy Based Routing (PBR). PBR using ACLs is the only supported method of doing QOS on ADP interfaces.

00257101 An ESP packet fragmentation problem with VPN driver was fixed. This affects IP560, IP690, IP1280, IP2450 VPN driver.

00493154 Interoperability with Nortel 8608SXE cards has been enhanced. The Nokia NIC now detects SYNC/IDLE.

00256507 The IPSO 4.2 build 105 SNMPD daemon reports 0 for the OID .1.3.6.1.2.1.2.2.1.10 (ifInOctets). This is now fixed to return valid result.

00258034 Improved stability of ADP (bpl_np_down_timer crash fixed).

00257485 If QoS is enabled, after a couple of hours the ethernet interface stopped responding to arp requests. This has been fixed.

00493061 A crash in net_sc_intr() has been fixed.

00550041 These following ethernet driver error messages have been fixed:wx0: No IDLE chars! wx0: NOTIFY interface that link partner is down!

00257647 When QoS is configured and the interface is enabled, the IP Appliance continues to operate properly.

ID Symptoms



00493364 When handling IPv6 traffic, the operating system is now stable.

00257222 Expired multicast connections are now deleted from the routing table.

ID Symptoms


Known Limitations and Configuration Tips

Known Limitations and Configuration TipsThis section includes tips and limitations that are applicable to this release and to previous releases of IPSO 4.2:

Known Limitations Found in IPSO 4.2 MR9Known Limitations Found in IPSO 4.2 MR7Configuration TipsADP LimitationsIP2450 LimitationsHigh-Availability LimitationsLimitations Related to Check Point NGXOther Limitations



Known Limitations Found in IPSO 4.2 MR9This section lists the limitation found in IPSO 4.2 MR9:

ID Symptoms

00556187 GPRS Tunnelling Protocol (GTP) acceleration is not supported with IP Clustering on FireWall-1 GX gateways.

0055329000553369

For Firewall-1 GX, to get correct statistics in fwaccel connections, the acceleration option in SmartDashboard and the cphwd_gtp_accel_enable setting must be either enabled or disabled.

To set the acceleration option in SmartDashboard (disabled by default):a. Use the gtp_v0_default or gtp_v1_default service in a

Firewall rule.b. Double-click the service to open the properties.c. Click Advanced.d. Select Accelerate GTP user traffic (with SecureXL).To set the cphwd_gtp_accel_enable (enabled by default):a. Confirm the value setting with the command:

fw ctl get int cphwd_gtp_accel_enable

b. Set the setting's value:To enable the setting, run: fw ctl set int cphwd_gtp_accel_enable 1

To disable the setting, run: fw ctl set int cphwd_gtp_accel_enable 0



Known Limitations Found in IPSO 4.2 MR7This section lists the limitation found in IPSO 4.2 MR7:

ID Symptoms

00256136 Check Point NGX R65 HFA50 can only be installed on flash-based IP Appliances with 1 GB of or more flash memory. For IP355 and IP385 models with less memory you must upgrade the flash to 1 GB or more before you can install R65 HFA 50. To purchase additional memory, contact your Check Point Support representative.

00256137 To install Check Point NGX R65 HFA 50, you must use the procedure described in “Installing on IPSO Diskless” in the NGX R65 HFA_50 Release Notes http://supportcontent.checkpoint.com/documentation_download?ID=10141 .

00256140 When restoring an IP Appliance image from backup, no warning is given when the restore has failed due to a full disk. The message is "Restore from Local: the restore has not yet finished, please wait 15 seconds and then reboot." To find out if the cause of the failure is a lack of disk space, enter the shell and run the df command and look at the “Avail” column of the output. If it contains a negative number, then one of the partitions on the disk is out of space. This means that the restore failed or that there is not enough space to perform the restore. For more information, see SecureKnowledge solutionhttp://supportcontent.checkpoint.com/solutions?id=sk42653

00501503 If you use an IP cluster, use switches (recommended) or hubs to connect the cluster protocol networks. This will ensure proper failover in the event that one of the nodes drops out of the cluster. Do not directly connect the cluster protocol interfaces using a crossover cable.




http://supportcontent.checkpoint.com/solutions?id=sk42653


Configuration TipsThis section provides suggestions that you might find useful when configuring IPSO 4.2 on a Check Point IP security platform.

Using VRRP Preempt Mode and Auto-deactivationSome applications and protocols, such as the Check Point firewall and certain routing protocols, expect all traffic passing through a Virtual Router Redundancy Protocol (VRRP) group to be handled by the same system. This requirement means that one system must be the VRRP master on all the networks connected to that VRRP group and that any failure should result in a failover of all the virtual addresses to the same backup system. Check Point’s monitored circuit implementation of VRRP ensures this behavior. If you use monitored circuit VRRP, you can use Preempt Mode and Auto-deactivation to ensure high availability while simultaneously maximizing network stability.

00256139 When configuring a VRRP IPv6 cluster, you must also configure an IPV4 VRRP cluster on all the cluster interfaces. This necessary in order to allow synchronization between the cluster members.

00497292 In a Legacy VRRP cluster configuration, failover does not work when the sync interface speed setting is Auto Advertise. As a workaround, turn off Auto Advertise on the sync interfaces and set them to a fixed speed (such as 1000 Mbps full duplex for a 1 Gbps interface)

00256143 The system terminates unexpectedly when LAG and VRRP are configured with vmac=interface on a system with on-board Ethernet (such as IP390). As a workaround, use an add-on NIC.

ID Symptoms



Using Preempt Mode

You can constrain the number of VRRP transitions (changes of master) by disabling the Preempt Mode option. The effects of enabling or disabling this option are summarized below:

Preempt Mode enabled (the default setting): If the original master fails, a backup system becomes the acting master (a failover occurs). When the original master returns to service, it becomes the master again (a failback occurs).Preempt Mode disabled: If the original master fails, a backup system becomes the acting master. When the original master returns to service, it does not becomes the master again (a failback does not occur).

A system with Preempt Mode disabled allows any other system—even one with a lower priority—to be VRRP master. Configuring this setting on a master is useful when you want to prevent the VRRP transition that would occur when a failed master recovers and would normally reacquire forwarding responsibility from the VRRP backup.

Using Auto-deactivation

If Auto-deactivation is disabled (the default), the lowest allowable effective priority value is 1. With this priority, a virtual router can become master if no other VRRP routers exist on the network.If you enable Auto-deactivation, the effective priority can become 0. With this priority, the virtual router does not become the master even if there are no other VRRP routers on the network. If you enable Auto-deactivation, you should also configure the Priority and Priority Delta values to be equal so that the effective priority becomes 0 if there is a VRRP failure.

Using Preempt Mode with Auto-deactivation

You can use Preempt mode and Auto-deactivation to prevent a failed master from causing an extra VRRP transition when it recovers but still ensure high availability by using the following configuration:

Disable preempt mode on the configured master only.



Enable Auto-deactivation and configure the Priority and Priority Delta values to be equal on the configured backup only.

With this configuration, a recovered configured master (acting backup) does not take over if the acting master (configured backup) is functioning properly. However, if the acting master fails, the recovered configured master becomes the master again even though it has Preempt Mode disabled.

VRRP and Spanning Tree ProtocolIf you use the spanning tree protocol on Cisco switches in a network connected to Check Point systems running VRRP, also enable the Port Fast feature, which causes interfaces to be set to the spanning-tree forwarding state without waiting for the standard forward-time delay. If you use switches from another vendor, use the equivalent feature provided by that vendor.Using the spanning tree protocol without Port Fast or a similar feature can prevent VRRP failovers from occurring properly.

VRRP and Cascaded SwitchesDo not connect interfaces participating in the same VRRP virtual router to separate cascaded switches. For example, avoid the following configuration:

Master node: Interface of virtual router 1 connected to switch A.Backup node: Interface of virtual router 1 connected to switch B.Switch A and switch B connected by an uplink connection.

Using this configuration can prevent VRRP failovers from occurring properly.

IP2250 and IP2255 Management PortsThe Ethernet management ports on IP2250 and IP2255 platforms are designed to be used for the following purposes:

Managing the platformFirewall synchronization trafficIP cluster protocol traffic



Connection to a log serverIP2250 and IP2255 management ports are not suitable for forwarding production data traffic. Do not use them for this purpose.

Cabling an IP2450 Platform <PR 59433>

When cabling an IP2450 platform with copper cables, follow these guidelines:

If you directly connect two IP2450 platforms (back-to-back), use a crossover cable.If you connect an IP2450 to a switch or hub, use a straight-through cable.

Use Half Duplex with Hubs <PRs 58700, 64217>

When connecting a Check Point network security platform to a hub, configure the Check Point interface to use half duplex duplicity. If you set the interface to full duplex, the link will come up but many collisions will occur, which could cause the link to flap or fail.

Optional Disks Erased when SelectedWhen you select a hard disk or card as an optional disk, any existing data on the device is erased. If you remove a PC card that contains log files and want to permanently store the data, insert the card into a PC or other computer and save the data to that system before reinserting the card into a Check Point flash-based platform. <PR 45065>

The IPSO CLI allows you to reselect an optional disk that you have already selected by reissuing a set optional-disk command. Doing so repartitions the optional disk. <PR 56513>

Configuring Gigabit Ethernet Descriptor Size Gigabit Ethernet interfaces can drop packets under specific circumstances in which the CPU is too busy to service the interfaces in a timely fashion. This problem is most likely to occur if there is a large amount of unaccelerated



traffic, most of the traffic transits two interfaces, and both interfaces are Gigabit Ethernet.You can prevent this problem from occurring by increasing the number of descriptors that are available for some Gigabit Ethernet interfaces. This allows the system to temporarily store more packets while waiting for the CPU to service them. The system uses one descriptor per packet unless it receives jumbo frames (Ethernet frames larger than 1518 bytes), in which case it uses multiple descriptors per packet. (You must explicitly enable support for jumbo frames by configuring the MTU for a Gigabit Ethernet interface to be greater than 1518 bytes.)You can configure the number of descriptors by entering a value in the Descriptor Size field on the Network Voyager page for configuring physical Gigabit Ethernet interfaces. The acceptable values are 128, 256, and 512, and the default value is 128. The value you enter must be a multiple of 8.On IP2450 systems, you can optimize performance by setting this option to 256 if you are using four or fewer Gigabit Ethernet interfaces to forward traffic. (Management ports are not relevant.) If you configure an IP2450 to use five or more Gigabit Ethernet interfaces for forwarding, performance will be best if you leave the option set to the default value of 128.

CautionDo not set the descriptor size to 512 on an IP2450. Doing so can cause performance to degrade or traffic to be completely stopped.

This option is not available on IP2250 or IP2255 systems and is also not available for certain Gigabit Ethernet interfaces that can be installed in other platforms.

Configuring Remote Core Dump Servers <PR 59010>

You can configure flash-based systems to transfer both application and kernel core files to a remote FTP server. When you do so, IPSO uses the user name ftp and the password passwd to log into the remote server anonymously. Some FTP servers do not allow this user name and password for anonymous



logins. If this is true of your FTP server, you must create a user with this user name and password to allow IPSO to transfer application and kernel core files to the server.

Complete All Fields When Creating Users <PR 52479>

When you create a new user, you must fill in the fields for Username and UID and complete the entry for Home Directory. The home directory should be/var/emhome/<username>. If you do not complete these fields, an error message appears that says “not all fields are complete”.

Providing User Access to Monitor Pages <PR 51692>

When you assign a role that provides access to a feature, the user gets access to the configuration pages for that feature but not to the monitor pages. To provide access to the monitor pages, you must include the monitor privilege for that feature in the role definition.

SNMP User privpassphrase Option Inaccurately Displayed <PR 51849>

When you use the tab completion feature of the CLI to view the options for adding or modifying an SNMP user that has a security level of authNoPriv, the privpassphrase option is displayed. You do not need to set a privacy pass phrase for a user with a security level set to authNoPriv and you can ignore this option in this case. If you attempt to set a privacy pass phrase, a message appears indicating that this is not necessary.

Audit Log Setting Not Permanently Saved <PR 51861>

The system configuration audit log setting is not saved in the configuration file. You must reset it after a reboot to enable logging again. You set the system configuration audit log using Network Voyager by clicking System Logging under Configuration > System Configuration and selecting either



Logging of Transient Changes or Logging of Transient and Permanent changes. With the CLI, you set this parameter with the following command: set syslog auditlog <disable | transient | permanent>

Terminal Emulator Display Configuration <PRs 53184,

53382>

If you use a terminal emulator (such as Microsoft Windows HyperTerminal) to connect to an IP390 or IP560, the system may display undesirable foreground and background colors as selected by the emulator software. To allow the IP390 or IP560 to automatically select the colors (typically white letters on a black background), configure your terminal emulation software to recognize ANSI characters with full ISO color emulation. To configure HyperTerminal in this way, perform these steps:1. Pull down the File menu and select Properties.2. In the Properties dialog box, select the Settings tab.3. Set the emulation to ANSI.4. Click OK.As an alternative approach, you can disable ANSI emulation and manually configure the foreground and background colors.

Do Not Insert or Remove PC Card During Boot <PR

55218> Do not insert or remove a PC card while a Check Point platform is starting up (for example, before you see the login prompt at the command line). Doing this can cause the system to hang.

Route Maps with BGP Confederations <PR 51672> You cannot use route maps in BGP confederations. To configure route filters and redistribution for BGP confederations, use the Inbound Route Filters and Route Redistribution pages in Network Voyager.



Installing a New IPSO Image on an IP265 <PR 56716>

When you a previous system image on an IP265 to make room for a new image, wait a few minutes after deleting the previous image before you install the new one. The IP265 requires a couple of minutes to delete the previous image, and if you try to install a new image before it completes deleting the old one, you receive a message saying there is insufficient space for the new image.

Workaround to Disable ifwd Daemon <PR 56616>

Check Point firewall versions NGX R60 and later do not require the ifwd daemon. Whether the ifwd daemon is running or not has no affect on the firewall operation.If you want to permanently disable the ifwd daemon, perform these steps:1. In the Network Voyager navigation tree, select Firewall and Other

Packages.2. Click the Check Point Firewall-1 link.3. Click the off radio button after the Run ifwd daemon to monitor interface

changes? question.4. Click Apply.5. Because there is no Save button on this page, you need to save your

changes from another Network Voyager page:a. Go to any other Network Voyager configuration page.b. Click in a text box on the page. This enables the Save button.c. Click Save.

Applying Queue Class with WRR <PR 59308>

If you use the Differentiated Services functionality in IPSO 4.2 for traffic management, a problem can occur if you create a queue class that uses the



weighted round robin (WRR) scheduling discipline and then perform the following steps while the platform is processing traffic:1. Apply the queue class to an interface.2. Disable the queue class for the interface.3. Apply the queue class to the same or other interfaceAt this point, the platform might hang. If it does, you must restart it to return it to service.The problem is most likely to occur with the IP2450, though it can happen on other platforms.

NoteTo prevent this problem, stop traffic from flowing through the system while you apply the queue class.

ADP LimitationsThis sections explains known limitations related to Check Point Accelerated Data Path (ADP) services modules.

Issue with Incomplete Reporting of Input Errors <PRs

80534, 81954>

For certain Check Point ADP interfaces, the InErrs value displayed by Network Voyager can be less than the total number of errors because inq_drop errors (if any) are not included in the total. You cannot accurately view the number of inq_drops independently because these packet drops are not correctly reported by these interfaces. This problem occurs with the 1 Gigabit Ethernet ADP services modules for the following platforms:

IP2450IP1280



IP1260IP1220IP690IP560

The problem does not occur with 10 Gigabit Ethernet ADP services modules for these platforms.The problem also occurs with the two port Gigabit Ethernet ADP card and the 10 Gigabit Ethernet ADP card for the IP2250 and IP2255.

Issue with ADP Interface LEDs <PR 59595>

If you have an RJ-45 only ADP services module (one that does not use SFP modules) in an IP2450 or IP1280, a problem occurs if you disable the Autoadvertise option for an interface while there is no cable connected to the interface. In this situation, the interface link LED on the module illuminates, incorrectly indicating that the link is active. Voyager also incorrectly indicates that the link is active. This problem does not occur with fiber optic interfaces or with RJ-45 SFP modules.

IP2450 LimitationsThis section explains limitations specific to the IP2450 network security platform.

Excessive Log Messages After Removing Carrier <PR 58766>

If you warm swap a 6U PMC carrier card out of a Check Point platform, a message similar to the following is recorded in the log file:[LOG_NOTICE] monitord: md_ipsctl_iterate: ipsctl get error = 2, ifphys:eth-s1/s1p2

The message is repeated one time for each minute that the carrier card is not present in the platform.



Display Issue with Console Connection <PR 58820>

If connect to an IP2450 console or auxiliary port through an intermediary device, you might see meaningless characters in the display. This problem has been observed with a Cisco console server.

High-Availability LimitationsThis section includes information about limitations regarding the Check Point implementations of the Virtual Router Redundancy Protocol (VRRP) and IP clustering.

VRRP with Transparent Mode Issue <PR 54908>

If you use VRRP with transparent mode, a problem can occur if you do the following:1. From the VRRP master, you physically remove a NIC that has interfaces

participating in the VRRP and transparent mode groups.VRRP failover happens properly.

2. You reinsert the NIC that you removed.In this circumstance, VRRP failback happens properly, but existing connections might be dropped and new connections might not be established. To correct this problem you must restart the VRRP master.If you use VRRP with transparent mode and PIM is enabled, all the systems in the VRRP group crash and restart if any of the VRRP nodes receives multicast traffic. <PR 57930> <Fixed in 031>

VRRP Accept Connections Cannot Be Disabled <PR

52226>

If a Check Point firewall is installed on the system, the system can be accessed through a virtual IP address even if the Accept Connections to VRRP IPs option is disabled. This problem does not occur if the firewall is not installed.



VRRP Backup Addresses <PR 52563>

A VRRP backup IP address must be in the same subnet as an interface configured on the device. However, the system will accept an IP address entry that is not configured on the device without displaying an error message. When you configure VRRP, you should verify that the subnet of the backup address is configured on the system.

Telnet Session Dropped on VRRP Failback <PR 53430>

If there is a failover in a VRRP pair and a new master is established, any telnet session you initiate with the new master will be dropped if the original master comes back up and becomes the master again.

Issue with VRRP and OSPF <PR 57402>

If you use OSPF in a VRRP group and enable the Virtual Address option (so that OSPF runs only on the virtual IP address associated with the interface), a problem can occur in the following circumstances:1. There is a very large number of OSPF routes.2. A VRRP failover occurs.3. The VRRP master returns to service and a failback occurs.After the failback, the IPSO routing daemon (ipsrd) might crash and restart.

Issue with VRRP HDD Monitoring on IP560 <PR 57379>

If you enable the VRRP option Monitor HDD State on a flash-based IP560 that has a PC card installed and a hard disk installed but not selected as an optional disk, the VRRP router transitions to init state and a failover occurs if the disk fails.

Do Not Configure Nodes as NTP Server <PR 52178>

If you enable VRRP or clustering, do not use any of the nodes as an NTP server. An issue with xntpd can cause the node to enter into a continuous loop



of leave and join mode, thus disrupting traffic. You can still configure nodes to be NTP clients.

Out of State Packets in Clusters <PR 52244>

If an IP cluster receives out of state packets for a connection, the firewall might not be able to properly synchronize the connection between the cluster nodes. In this situation, the connection does not fail over if the node that is handling it leaves the cluster.You can prevent this problem from occurring by entering the following command at the IPSO shell on all the cluster nodes:fw ctl set int fw_allow_connection_traffic_drop 0 (default 1)

This command does not survive a reboot. To make the change in a way that is permanent, entermodzap \_fw_allow_connection_traffic_drop \ $FWDIR/boot/modules/fwmod.o 0

For more information about the modzap utility, see SecureKnowledge solution sk40041http://supportcontent.checkpoint.com/solutions?id=sk40041.

Issue with Cluster Backup and Restore <PR 54527>

Problems can occur with IP clusters if you do the following:1. Backup the configuration of a cluster master.2. Delete and reinstall the NGX package.

The system rejoins the cluster and becomes the master again.3. Restore the backed up configuration.In this circumstance, the following problems might occur:

The cluster master might stop forwarding traffic.The cluster members might hang.

If both problems occur, the cluster does not forward any traffic.


http://supportcontent.checkpoint.com/solutions?id=sk40041


To avoid this problem, perform the backup/restore procedure and reinstallation of NGX on all the cluster members.

AAA Not Cluster Sharable <PR 54561>

Starting with IPSO 4.1, Authentication, Authorization, and Accounting (AAA) is no longer a join-time shared feature in IP clusters. If you want to upgrade a cluster in which this feature is shared, make sure that it is no longer shared before you upgrade to IPSO 4.2. If you want to configure AAA in the cluster after you upgrade to IPSO 4.2, you must make the changes on the individual nodes.

CLI Display Issue with OSPF <PR 52052>

If you use OSPF in an IP cluster, a display issue occurs if the following sequence of events happens:1. A switch or hub failure causes all the cluster interfaces connected to the

switch or hub to fail, and OSPF was running on these interfaces.2. At a later point, an event (such as a reboot) causes ipsrd to restart on one

of the nodes.3. You use a CLI command to view the OSPF interfaces on the cluster

nodes. The affected interface does not appear on the node on which ipsrd was restarted.

This is a display issue only—the functionality of OSPF is not affected.

Cluster Voyager Response Time <PR 52548>

When you perform an operation with Cluster Voyager that affects all the cluster nodes, you might notice that the response time is slightly slower (several seconds) than with previous versions of IPSO. The functionality of the cluster is not affected by this change.



Error MessagesThis section describes some harmless error messages that might appear when you configure a cluster.

Error Message When Rejoining Cluster <PR 52591>

If a cluster is configured so that nodes leave the cluster if the firewall daemon on them is disabled, and you stop and restart the firewall on a node, you see messages similar to the following on the system that leaves and rejoins the cluster:vnode_pager_output: attempt to write meta-data!!! -- 0xffffffe9(ff)

Sep 13 15:30:16 cl1 [LOG_CRIT] kernel: vnode_pager_output: attempt to write meta-data!!! -- 0xffffffe8(ff)

Each message might be repeated several times. The node rejoins successfully and there is no effect on the cluster’s functionality.

Error Message When Deleting Cluster <PR 52375>

If you have a firewall installed in a cluster and delete the cluster, you might see a message similar to the following:FW-1: fwha_nokcl_creation_f: error in de-registration to the cluster join (3)

Sep 13 03:07:17 IP2250-B [LOG_CRIT] kernel: FW-1: fwha_nokcl_creation_f: error in de-registration to the cluster join(3)

This message is harmless and can be ignored.

Limitations Related to Check Point NGXThese sections describes limitations related to NGX R62 and R65 running on IPSO 4.2. Note that some of these limitations might have been fixed by subsequent HFAs from Check Point. Consult the HFA release notes to determine whether or not a limitation has been fixed.



Limitations for Flash-Based PlatformsWhen upgrading to NGX R62 on a flash-based platform, install the VPN-1 Pro/Express and Cpinfo packages separately rather than using the comprehensive wrapper package. Install the VPN-1 Pro/Express package first, and then install the Cpinfo package. <PR 56630>

When you use Check Point Network Voyager to disable the Check Point VPN-1 Pro/Express and CPinfo packages on flash-based platforms, the firewall fwd and cpd processes do not stop. However, when you reboot the platform after disabling the packages, the platform restarts with the processes stopped. <PR 42681>

By default, the firewall does not log locally on a flash-based platform if the log server becomes unavailable. As a result, logs generated while the log server is unavailable are lost. However, on flash-based platforms that allow you to use a hard disk as an optional disk, you can configure the platform to use an installed hard disk to store firewall logs locally. To use this feature, you must have a version of the Check Point firewall installed that supports local logging to optional disk. As of the publication of this document, local logging is supported only by NGX R62 with a required hotfix applied. Other versions might support it in the future; contact Check Point support for current information.For information on how to configure Check Point firewall logging to an optional disk, see “Support for Check Point Local Logging on Optional Disks” on page 108.SmartView Monitor history files are lost when a flash-based platform is rebooted. <PR 42681>

Limitations Specific to the IP265Check Point strongly recommends that you use the external flash-memory PC card that is supplied with your IP265 to store the Check Point packages. Doing so expands the internal memory available to the firewall. <PR 58079>



To store the Check Point packages on the flash-memory PC card:a. Install or upgrade VPN-1 Pro/Express.

NoteTo install or upgrade to NGX R60 on an IP265, use the latest NGX R60 package from Check Point designed for the IP265. As of the publication of this document, the latest package is R60_HFA_03 for the IP265. Use newpkg to install this package.

If your platform came with NGX R60 preinstalled, you must upgrade it using the HFA for the IP265. <PRs 44994, 50236>

NoteTo upgrade to R61 from a previous version, you must have already configured your IP265 to use the optional flash memory to store the Check Point packages.

b. Install the flash-memory PC card in slot 2. Do not use slot 1. <PR 55434>

c. In the Optional Disk Configuration page in Network Voyager (Configuration > System Configuration > Optional Disk), click the radio button under Packages. Then click Apply and Save.

d. When you see a message telling you that you should reboot, reboot the system.

You must reboot the IP265 whenever you select or deselect the Packages option under Optional Disk. If Check Point packages are installed, this reboot can take as long as 10 to 12 minutes complete. This is normal: do not reboot the platform again while the original reboot is still in process. If the IP265 is rebooted again before the first reboot completes, the Check Point installation might become corrupted. If it is corrupted, you must reinstall the Check Point packages. <PR 55259>



Limitations Related to Package Installation or ManagementThis section describes limitations that are specific to the processes of installing or managing packages.

Upgrading to NGX R65

If you upgrade from any NGX version to NGX R65, you can install and initially configure the UTM features.

Issues with Remote Installation <PR 57085>

You can use a network connection to upgrade to NGX R65 if you establish an SSH connection before you begin the upgrade. Use this connection to reboot the system when the upgrade is complete.

NoteBe sure to create the SSH connection before you begin the upgrade to R65.

You should use a console connection to upgrade to NGX R62 because the Check Point initial policy is installed after the upgrade, which causes you to lose network connectivity to the platform. Do the following to reestablish network connectivity between the gateway and the management server:1. Log in using a console connection.2. View /var/log/newpkg.log to check if the upgrade is complete.



You should see the following message displayed at the end of the file if the upgrade is complete and without errors:

********INSTALL/UPGRADE PROCESS COMPLETED****** Please do the following if the INSTALL/UPGRADE is Successful:

1) Logout and re-login.

2) Run \'cpconfig\' and configure the firewall.

3) Install the new License if required.

4) Reboot the box.

********INSTALL/UPGRADE PROCESS COMPLETED******

3. Close the file.4. Enter reboot at the prompt.After the platform reboots, you can access the platform from your management server.

Delete Directories After Reinstall <PR 57975>

If you delete the Check Point packages, you must manually delete the /opt/CA and /opt/uf directories before you reinstall the packages.

Block Data Connection Is Enabled <PR 58582>

When you upgrade from NGX R62 to NGX R65, “Block data connection to all defined service ports” is enabled in SmartDefense. This blocks dynamic UDP ports and VoIP-SIP traffic.

Error Message On Upgrading From NGX R60 <PR 58112>

Upgrading using the newpkg command from NGX R60 HFA04 to NGX R65 displays the following error message:FW-1: fw_runfilter: illegal kfunc 0x7b at 0x7d49

Ignore the error message. This does not affect the success of the upgrade.



Incorrect SecureXL Version Reported <PRs 57803, 58646>

When you install NGX R65, IPSO incorrectly reports the version of SecureXL as 2.55. The correct version is 2.22, and it does not support aggressive aging.

Do Not Use Wrapper on Flash-Based Platforms <PR 56630>

When upgrading to NGX R62 on a flash-based platform, install the VPN-1 Pro/Express and Cpinfo packages separately rather than using the comprehensive wrapper package. Install the VPN-1 Pro/Express package first, and then install the Cpinfo package.

IPSO Version in Package Information <PR 52208>

Network Voyager displays information about an NGX R60 or NGX R61 package after you unpack the package as part of package installation or upgrade. The IPSO version is displayed is the 3.9 rather than 4.1. This is the base IPSO version that supports NGX R60 and NGX R61.

Cluster Going into Initialized State after Package Installation <PR 52333>

Under certain circumstances, a cluster running NGX VPN-1 Pro/Express might go into an initialized state when you install a package. This can happen if you attempt to install a package immediately after performing a fresh installation of the image and performing the initial configuration of both the firewall and clustering, but before you have performed any other package management activity.If you encounter this problem, perform any package management activity (for example, save the configuration from the Manage Packages page) and then stop and restart the firewall.

Inaccurate Installation Message <PR 44880>

When you install a package using Voyager, you see the following message:Voyager environment has been updated with the latest package info.

The telnet session environment will be updated by:

logging out and logging in again the telnet session.



This message might not be accurate. Click Manage Packages to verify that the package is installed. Refresh the page periodically until you see that the installation is complete.

Limitations for Anti-virus and URL FilteringThese sections describe limitations related to anti-virus and URL filtering with NGX R65 running on IPSO 4.2.

Kerberos-based FTP Not Supported <PR 57802>

If anti-virus is enabled on a gateway, FTP clients cannot connect using Kerberos authentication because the traffic is encrypted.

Disable Anti-virus and URL Filtering When Running IPSO Security Servers <PR 57840>

You must disable anti-virus and URL filtering when IPSO security servers (fwssd) are running so that Network Voyager access and FTP/SMTP/POP/HTTP services are allowed.

IPv6 Not Supported <PR 57805>

IPv6 is not supported.

Disable Check Point Packages Before IPSO UTM Base Package <PR 57888>

Do not disable the IPSO UTM Base package while the Check Point VPN-1 Power/UTM NGX R65 package is still enabled even though Network Voyager and the CLI allow you to do so. Do not disable the IPSO UTM Base package and the Check Point VPN-1 Power/UTM NGX R65 package simultaneously either. To disable the packages, first disable the VPN-1 Power/UTM NGX R65 package and then disable the IPSO UTM Base package.



Anti-virus Connections Do Not Failover <PR 58137>

In a VRRP or cluster environment, anti-virus connections do not failover or failback. If you have a failover or failback, you need to initiate a new connection.

Aggressive Aging Not Supported <PR 57803>

Aggressive aging is not supported.

Install Identical Policies On Gateways Managed By Same Management Station <PR 57943>

You cannot install different anti-virus policies on gateways managed by the same management station.

Large Email Attachments Corrupted <PRs 58992, 58993>

When AV/URL filtering is enabled, email messages larger than 900 KB sent through http-OWA are corrupted.It may not be possible to upload or attach files that are larger than 900 KB on general web mail sites, for example, Yahoo. This condition happens only when “Active continuos download” is On for HTTP. Configure “Active continuos download” as Off. This is the default setting.

Use Name And IP Address for URL Filtering <PR 58712>

When you block web sites with URL filtering, you must add both the name and the IP address of the web sites to the filtering list.

SmartDefense Shows Error Message <PR 58097>

SmartDefense services tab shows that AV/URL filtering is not deployed. This error message is due to the signature not being deployed.

No Logging for Dropped Malformed Packets <PR 81955> Systems running IPSO 4.2 Build 096 with SecureXL enabled will drop certain malformed packets. Because these are dropped upon their input into the



IPSO kernel, the firewall logs will not show if any packets of this type have been received.

Use Linux FTP Clients For File Transfer <PR 58852>

If you download or upload large files using Windows ftp clients or servers, the connection is aborted in the middle of the file transfer. If the file is a .zip or .exe, it cannot be extracted. Use Linux ftp clients for file transfers.

Disable Continuous Download For POP3 <PR 59525>

Configure continuous download as Off if you use a GNU POP3 server while anti-virus is enabled. If continuous download is On, email infected with viruses will not get deleted and clean email cannot be retrieved.

Use Default HTTP setting for Continuous DownloadUse the default HTTP setting for continuous download. The default setting is Off.

Remove Old Files From $FWDIR/tmp <PR 58092>

If $FWDIR/tmp is full or near full, you should remove files that have older time stamps.

Templates Not Created for DNS Traffic <PR 58092>

Templates are not created for DNS traffic (UDP or TCP).

Zero Downtime Upgrade Not Supported <PR 58310>

A zero downtime upgrade from NGX R62 to NGX R65 is not supported.



Error Message When Enabling SMTP Resource <PR

58311> When you enable an SMTP resource in the rule base, you get an anti-virus engine initialization failure.

Accessing https Sites From Behind Gateway <PR

58320>

You cannot access https sites from behind the gateway through a proxy server with the Next-Proxy IP settings enabled in the Authentication section of the gateway properties. Do the following in SmartDashboard:1. Disable SmartDefense default-protection profiles for the gateways.

Download the policy to the gateways.2. In Policy/Global Properties, Under SmartDashboard-Customization node,

click Configure.3. In the Advanced Configuration window, Under Firewall-1 > Web

Security > HTTP Protocol, check http_connectio9n_method_tunneling.4. In the SmartDefense tab, go to Web-Intelligence > HTTP Protocol

Inspection > HTTP Methods.5. In Protection Scope, enable “Apply to all HTTP traffic.”6. In Blocked HTTP Methods Configuration, enable “Block Selected HTTP

Methods” and click Configuration.7. Uncheck the “CONNECT” method and click on OK.8. Enable SmartDefense default-protection profiles for the gateways.9. In SmartDashboard, download the policy update to the gateways.10. Access the https sites through the proxy.

Scan By IP Only In Transparent Mode <PR 57942>

An IPSO system can only “Scan by IP” and not by “Scan by Direction” when transparent (bridge) mode is enabled.



Disable Security Servers For RTSP StreamingRTSP streaming over http does not work if http security servers are running.

Multicast Traffic Not NATed <PR 57998>

If NAT is enabled on the firewall and multicast traffic is sent from the protected network, this traffic is not NATed by the firewall—the source addresses of the packets are not changed.

Diagnostic Command Not Supported <PR 57386>

The command fwaccel diag is not supported by NGX R62. It also does not work if you execute it on an NGX R60 or NGX R61 gateway managed by a NGX R62 management system. In this circumstance the system will return a segmentation fault and create the core dump file fwaccel.core in the /var/admin directory.

SecuRemote/SecureClient Drops Connections After VRRP Failover <PR 53538>

If you are using VRRP and IP compression is enabled, SecuRemote/SecureClient might drop the connection if there is a VRRP failover. This problem occurs only if IP compression is enabled.To work around this problem, disconnect and then reconnect SecuRemote/SecureClient.

Encryption Bytes Statistic Not Updated <PR 53819>

The enc bytes statistic displayed in the output of the fwaccel stats command is not updated by the system. It always displays as 0, even when encryption is operating on the system.



Connection Failure after Cluster Failback with Client Authentication <PR 52483>

If you use the Specific Sign On option for Client Authentication to establish a connection with an internal host, that connection might fail after a cluster failover or failback. The log for the connection will contain “packet out-of-state” messages. This problem does not occur if you use the Standard Sign On option.

VRRP Failback and Maximum Connections <PR 54541>

If the number of concurrent connections reaches the maximum configured, and the VRRP master fails, failover to the backup member works normally. However, if the master recovers while the number of connections are at maximum, failback to the master might not work normally, with both VRRP members being master for a long time.

FTP Connection Failure with User Authentication in Cluster <PR 52322>

If a cluster is configured with static NAT for an internal host and you attempt an FTP connection to the internal host from an external host using User Authentication, the FTP connection fails. The log for the connection attempt will contain “TCP packet out of state” and “Packet is not SYN” messages.

Anti-virus Prevents FTP with Kerberos <PR 57802> If anti-virus is enabled on a gateway, FTP clients cannot connect using Kerberos authentication because the traffic is encrypted.

VRRP VIP Address Connection Failure <PR 52323>

If you establish a connection to the virtual IP address (VIP) of a VRRP pair running VPN-1 Pro/Express and then a failover occurs, the connection might stop responding. If this occurs, stop the existing connections and retry the



connection. This affects only persistent connections to the VIP of the VRRP pair and not any other connections.

Incorrect Gateway Overall Status in SmartView Monitor <PR 52428>

If you connect to an NGX SmartCenter on an IP security platform with the SmartView Monitor, you might see “Bad Reply” in the Overall Status field in the All Gateways view. If this happens, confirm the actual status of the gateways by checking the Firewall Status field in the Firewalls Gateways view.

Asset Summary Information for Cluster Voyager and CLI <PRs 52228, 52713>

The Cluster Voyager Asset Summary page and Cluster CLI show asset packages command do not display Check Point package information correctly.

Log Messages After Deleting a Cluster <PR 52434>

If you have NGX R60 running on a cluster and then you delete the cluster, you will see the following message repeated continuously in the log after the deletion:netlog:nok_cluster .. nokcl_packet_to_member called when no IPSO clustering or VRRP configured.

This message is harmless.

ISP Redundancy Not Supported in Clusters <PRs 53727,

53729>

Check Point's ISP redundancy feature does not work properly with IP clusters. Do not include ISP redundant interfaces in clusters.



Route-Based VPN and Virtual Tunnel InterfacesThe following limitations apply to the Check Point Route-Based VPN feature and virtual tunnel interfaces on IPSO:

Dynamic routing over virtual tunnel interfaces is not supported in IP cluster configurations.tcpdump cannot monitor virtual tunnel interfaces on Check Point platforms. If you try to use it to monitor a virtual tunnel, you will receive a “Device not configured” message. <PR 45084>

The IPSO CLI does not support creating and managing virtual tunnel interfaces. Use Network Voyager or the Check Point VPN shell for these tasks. <PR 45137>

Multiple Interfaces Enhancement <PR 44876>

NGX R60 includes a feature to prevent routing asymmetries that can occur with SecureClient connections if your gateway has more than one external interface. You use this feature by accessing the Gateway Properties/Remote Access/Office Mode window and checking the box next to “support connectivity enhancement for gateways with multiple external interfaces.”If you enable this feature in an IP cluster running IPSO 4.2, you will not be able to establish SecureClient connections with the cluster.

Transparent Mode and SmartDashboard <PRs 29752,

49514>

When you use SmartDashboard to configure the Gateway Cluster properties of a VRRP pair that uses IPSO transparent mode, you must follow this procedure:1. Create a gateway object for each of the VRRP nodes.2. Define the topology for each gateway object. Make sure that transparent

mode is properly configured with the address ranges to the external and internal networks correctly defined.

3. Create the cluster object.



4. Add each gateway to the cluster object using the Add Gateway to Cluster button.

If you use the New Cluster Member button to add a VRRP member that uses transparent mode to a cluster, you cannot correctly configure the topology.

Cannot Ping Local IPv6 Interfaces <PR 44324>

If you use IPv6, you cannot ping local IPv6 interfaces. This does not affect functionality—IPv6 forwarding works properly.

Inability to Connect from Backup Member to VLAN HostYou might experience difficulty connecting to a host in a VLAN from a backup VRRP or IP cluster member when you have more than one VLAN configured on a Link Aggregation Group. Connections from the backup member to hosts in the untagged VLAN or in the first VLAN will work; however, you might not be able to connect to hosts in the other VLANs. <PR 55325>

FloodGate-1 Package Message <PR 44134>

You might see the following message at the command line under certain circumstances, such as when firewall services start or you execute the etmstart command:FloodGate-1 package is off - Please use the voyager to turn it on

Because FloodGate-1 is no longer delivered as a separate package, you cannot use Network Voyager to turn it on. Instead, if you wish to enable FloodGate-1 (QoS), use the SmartDashboard to select QoS in the gateway General Properties tab and then push the policy to the gateway.

Limitations Specific to NGX R60This section describes limitations that apply only to running NGX R60 on IPSO 4.1.Note that some of these limitations might have been fixed by



subsequent NGX R60 HFAs. Consult the HFA release notes to determine whether or not a limitation has been fixed.

Limitations Specific to the IP265 and R60To install or upgrade to NGX R60 on an IP265, use the latest package from Check Point designed for the IP265. As of the publication of this document, the latest package is R60_HFA_03 for the IP265. Use newpkg to install this package. <PRs 44994, 50236>

The HFA for the IP265 allows the Check Point packages to be installed on the external flash-memory PC card that is supplied with your IP265, expanding the internal memory available to the firewall. Check Point strongly recommends that you use your external flash-memory PC card to store the Check Point packages.To store the Check Point packages on the flash-memory PC card:a. Using the HFA for the IP265, install or upgrade VPN-1 Pro/Express. If

your platform came with NGX R60 preinstalled, you still must upgrade it using the HFA for the IP265.

b. Install the flash-memory PC card in slot 2. Do not use slot 1. <PR 55434>

c. In the Optional Disk Configuration page in Network Voyager (Configuration > System Configuration > Optional Disk), click the radio button under Packages. Then click Apply and Save.

d. When you see a message telling you that you should reboot, reboot the system.

You must reboot the IP265 whenever you select or deselect the Packages option under Optional Disk. If Check Point packages are installed, this reboot can take as long as 10 to 12 minutes complete. This is normal: do not reboot the platform again while the original reboot is still in process. If the IP265 is rebooted again before the first reboot completes, the Check Point installation might become corrupted. If it is corrupted, you must reinstall the Check Point packages. <PR 55259>



Limitations Specific to NGX R61These sections describes limitations related to the base NGX R61 release running on IPSO 4.1. Note that some of these limitations might have been fixed by subsequent NGX R61 HFAs. Consult the HFA release notes to determine whether or not a limitation has been fixed.

Limitations for Flash-Based Platforms

The following limitations apply to installing or upgrading to R61 on flash-based platforms:

Do not use Network Voyager to upgrade to R61 from a previous version. Instead, use the newpkg command. <PR 55958 >

Before you can upgrade an IP265 running a previous Check Point version to R61, you must have the IP265 configured to use the optional flash memory to store the Check Point packages.

Network Voyager and Check Point Package Options

The following limitations are specific to how Network Voyager handles options relating to Check Point NGX R61.

When you enable or disable the R61 packages from Network Voyager, you might see the following messages on the console:xpand[474]: parse_manifest: Couldn't open file /opt/CPsuite-R61/ fw1/MANIFEST: No such file or directory

These messages are harmless and can be ignored. <PR 55963>

Other LimitationsThis section includes information about limitations not specific to the high availability features in IPSO or to Check Point applications.



IPSec Not Natively Supported on IPSO <00258407>

IPSec is no longer natively supported on IPSO, which means that IPSec VPNs cannot be created without a Firewall. As in all previous versions, IPSec VPNs can be created on the Firewall using SmartDashboard.

Repeated Interface Down Messages <PRs 59311, 79849>

If you deactivate a physical Ethernet interface Under certain circumstances, the log message generated by deactivating the interface repeats every few seconds.If this happens, you might be able to resolve the issue by rebooting the platform or by disabling the logical interface while keeping the physical interface enabled.

Issue with Fresh Installation of IPSO 4.2 from 4.1 Build 016 or 019 <PR 56221>

Avoid using the IPSO boot manager to install IPSO 4.2 on a platform running IPSO 4.1 Build 016 or 019 if you installed the 4.1 build using the boot manager. If you attempt to upgrade in this way, the system might repeatedly panic and reboot.To upgrade these systems to IPSO 4.2, use Network Voyager, the CLI, or the newimage shell command.

Issues with Link RedundancyThis section includes information about limitations related to the Ethernet link redundancy feature.

Issues with ADP Cards and Link Redundancy

If you configure a link redundancy group using interfaces on a Check Point Accelerated Data Path (ADP) card for a Check Point IP560, Check Point IP1220, or Check Point IP1260 platform, a problem occurs if you later remove interfaces from the group. If you remove an ADP interface from a link



redundancy group and configure it with its own IP address, the interface does not forward traffic until you restart the platform. <PR 59949>

If you create a link redundancy group using one of these ADP interfaces, you cannot use tcpdump to monitor the activity of the group. The interfaces in the group forward traffic properly, but tcpdump does not display any information about the activity. <PR 64039>

Interfaces Configurable After Warm Swap <PR 59507>

A problem occurs if you do the following:1. You configure interfaces on a carrier card to be link redundant.2. You warm swap the carrier card out of the platform.3. You later reinsert the carrier card.After you reinsert the carrier card, IPSO incorrectly allows you to reconfigure the logical characteristics of the individual interfaces in the link redundancy group. You should only perform logical configuration on the entire group, and IPSO should enforce this constraint.If you reboot the system, IPSO correctly enforces the constraint after the reboot.

Issue with Fresh Installation on Specific Platforms <PR 57892>

NoteThis issue fixed in Build 031

Do not attempt to perform a fresh installation of IPSO 4.2 (use the boot manager to install IPSO) on any of the following platforms if the system has less than 512 megabytes of memory:

IP350IP355IP380



IP385To upgrade these systems to IPSO 4.2, use Network Voyager, the CLI, or the newimage shell command.

Issue with Using PC Card to Install IPSO <PR 55348> If you install IPSO 4.2 by putting a copy of the file ipso.tgz on a PC card and using the newimage command option 4 to install from the local filesystem, IPSO installs correctly but the .tgz file is deleted from the card and the card is unmounted after the installation is complete.

Boot Manager and Optional Disk Configuration <PR

56562>

When you perform a fresh installation of IPSO on a flash-based platform that has an optional disk installed, you are asked if you want the boot manager to configure the optional disk for logging. If the optional disk is an unlabeled hard disk, the boot manager lists the disk as unsupported and you are unable to configure it for logging.To work around this issue, continue with the installation of IPSO. After you perform the initial configuration, log in to Network Voyager and use the Optional Disk Configuration page (Configuration > System Configuration > Optional Disk) to configure the optional disk.

Optional Disk Commands and Non-Admin Users <PR

56510>

The CLI optional disk commands (for example, show optional-disks or set optional-disk) do not work correctly for all users who have administrative privileges for optional disks. These commands work properly only for the admin user or any user with a UID of 0.When a user who has admin privileges but who does not have an UID of 0 executes a CLI optional disk command, the CLI treats all optional disks as if they are unsupported, even if they are supported and properly labeled.



To work around this issue, log in to the CLI as the admin user or use Network Voyager to configure optional disks.

Issue with IP265 Optional Disk (Flash Memory) <PR

55434>

If you install a flash-memory PC card in slot 1 of an IP265 and configure it as an optional disk, the system does not restart successfully. To avoid this problem, install the PC card in slot 2.

Issues with Logging on Flash-Based PlatformsThis section contains descriptions of some issues in IPSO 4.2 related to logging IPSO messages from flash-based platforms.

Cannot Mirror Logging Disks <PR 55360>

Some Check Point flash-based platforms allow you to store log files on optional hard disks. This is called a hybrid mode configuration—IPSO and the firewall are stored in flash memory and log files are stored on the disk. IP560 and IP1200 Series platforms allow you to install two hard disks, but you can use only one disk at a time when using hybrid mode. Do not enable disk mirroring when using hybrid mode.

NoteYou can use disk mirroring with disk-based IP560 and IP1200 Series platforms (in which IPSO and the firewall are stored on a disk).

Messages Lost when Remote Server Is Down <PR 51838>

Some logging messages might be lost when a flash-based (diskless) platform tries to send messages to a remote logging server that is down or otherwise unreachable. This problem occurs only on flash-based platforms and only when a large number of messages (over 150 or so) are generated during the period the system is trying to reach the remote server. During this interim period in which the Check Point system is trying to discover whether the



remote server is down, only those messages generated after the first 150 are lost. When the Check Point system determines the remote server is down, no more messages are lost. The system tries to connect again in five minutes, and the same sequence occurs if the remote server is still unreachable.

Messages Lost when Local Logging is Off <PR 53553>

If you disable local logging and enable remote logging, some logging messages might be lost. If you enable both local and remote logging, this problem does not occur.

Link Aggregation with IP225x <PRs 54483, 54484, 55193, 55372> If you have an IP2250 or IP2255 and use link aggregation, a problem can occur if you remove the cable of an aggregated interface or remove the interface card itself. In this situation, the duplex setting of the removed interfaces might change, which disables the aggregation group because the physical configuration must be identical on all the interfaces in the group. If this occurs, you must delete the affected ports and then reconfigure the aggregation group appropriately. You cannot make any changes until you delete the affected ports. If the primary port is affected, you must delete the group and create a new one.

Issue with UDLD under Heavy Traffic <PR 55481>

If you enable the Cisco Unidirectional Link Detection (UDLD) protocol on a fiber-optic interface (to improve detection of partial link failures), a problem can occur if the platform receives very heavy traffic. Under this condition, some UDLD packets might get dropped, which causes IPSO to see the link as unidirectional and deactivate the interface.

Issues with Nonlocal Users This section describes issues with the IPSO feature that allows you to create user accounts only on RADIUS and TACACS+ servers. When configured properly, Check Point systems will accept these users even though there are no local accounts for them.



Issue with clusterAdminRole <PR 54721>

If you create a nonlocal user account (for example, on a RADIUS server) and assign the clusterAdminRole to the account, that user can log into the Check Point system even if clustering is not enabled.If the user logs in using Network Voyager they cannot configure the system. If they log in using the IPSO CLI, they can make configuration changes.

Logging Issue with Voyager <PR 54584>

If a nonlocal user logs in using Network Voyager, Voyager does not display the correct log information about the session. The only message that Voyager displays about the session is HTTP login from x.x.x.x as xxxx

You can see the correct log messages for the session by using the CLI.

Log In Issue <PR 55118>

If a nonlocal user attempts to log in but provides an invalid password, they cannot log in during that session even if they provide the correct password in later attempts. To successfully log in, they must start a new session and provide the correct password.

10 GigE Interfaces Do Not Reactivate <PR 53163>

If you connect the 10 Gigabit Ethernet NIC to a Cisco switch and deactivate and reactivate a connected interface on the switch using Cisco commands, the corresponding interface on the 10 Gigabit Ethernet NIC might not be reactivated properly. You can work around this problem by entering the commands shutdown and no shutdown again on the Cisco system.

DHCP Server Issue with Multiple Subnets <PR 53365>

If you enable the DHCP server for an interface and that interface has multiple addresses (in different subnets) configured for it, the DHCP server might fail to respond to some DHCP requests received on that interface.



To workaround this issue, configure a DHCP subnet for the subnet of every address configured for the interface.

ACL Queue Class Configuration Issue on IP225x <PR

53969>

If you create an access control list (ACL) on an IP2250 or IP2255, you cannot configure a useful queue class for the ACL because you cannot include interfaces on the I/O cards in the queue class. The only interfaces that are available for inclusion in the queue class are the built-in 10/100 Ethernet management ports. However, you should not use these ports for production traffic, so it does not make sense to include them in a queue class.

Issue with Changing User Password <PR 53998>

When you change a user password on the Change Password page of Network Voyager and click Apply and then click Save, the system does not accept the new password. The system displays the error message Old Password field is empty.To work around for this problem, click Save immediately. Do not click Apply.

pppoE Configuration Issue <PR 54907>

If you create an unnumbered logical pppoE interface, Network Voyager does not display loopback interfaces in the list of available proxy interfaces. To work around this issue, use the CLI commandadd interface pppoe0 mode unnumbered logical-interface log_if_name profile-name profile_name

and enter the name of the appropriate loopback interface.

Issue with Hardware Acceleration Statistics <PR 57389>

If you enter the CLI commandshow cryptaccel statistics



on an IP560 or IP1200 Series platform that has a hardware cryptographic accelerator installed, IPSO does not return any information about performance of the accelerator.

SNMP IssuesThis section describes issues with the implementation of the Simple Network Management Protocol (SNMP) in IPSO 4.2.

Issue with Creating SNMP Users <PR 51642>

When you configure a new SNMP user, occasionally the following error message appears:Failed to set pass phrase for SNMP USM user 'name', because the SNMP engine ID is unavailable (perhaps 'snmpd' is not running or not ready)

This occurs if you have not enabled the SNMP service or if the SNMP agent is still coming up. If you receive this error message, verify that SNMP is enabled. If it is not enabled, enable it and try creating the SNMP user again. If SNMP is already enabled, wait a few minutes and then try again.

Link Aggregation Traps Do Not Work <PR 54625>

IPSO should send the traps lamemberActive and lamemberInactive when a link aggregation group (logical interface representing one or more physical interfaces) is activated or deactivated. IPSO 4.2 does not send these traps.The traps for indicating the status of physical interfaces (linkUp/linkDown) work properly.

Incorrect Values for Disk and Memory Size <PR 55377>

SNMP returns slightly incorrect values for memory storage size and disk storage size. SNMP does not report any information for the following devices:

internal compact flash memoryexternal compact flash-memory PC cardsecond hard disk in an IP560






Documents

IPSO 4-2 MR9 Release Notes