Tag Archive for checkpoint

Checkpoint Firewall-1 and The SIP Protocol

You have an asterisk based VoIP phone system sitting on an internal network and you are trying to establish connectivity to a SIP-based trunk provider.

You configure a static NAT entry 1-to-1 for the asterisk box and allow the SIP (udp 5060) through the firewall, but SIP registration fails constantly.

While troubleshooting the issue you observe some strange behavior in the NAT. The SIP registration packet (source port 5060, destination port 5060) reaches the firewall, changes the source port at the interior interface and to another high port at the exterior interface, but the answer packet will not be translated correctly.

Fw monitor shows the following:

a.b.c.d is the internal (private) IP address
n.n.n.n is the external (public) IP address
w.x.y.z is the SIP providers IP address

eth1.10:i[502]: a.b.c.d -> w.x.y.z (UDP) len=502 id=0

UDP: 5060 -> 5060

eth1.10:I[502]: a.b.c.d -> w.x.y.z (UDP) len=502 id=0

UDP: 17973 -> 5060

eth0:o[502]: a.b.c.d -> w.x.y.z (UDP) len=502 id=0

UDP: 17973 -> 5060

eth0:O[510]: n.n.n.n -> w.x.y.z (UDP) len=510 id=0

UDP: 40625 -> 5060

eth0:i[404]: w.x.y.z -> n.n.n.n (UDP) len=404 id=5495

UDP: 5060 -> 40625

eth0:I[398]: w.x.y.z -> a.b.c.d (UDP) len=398 id=5495

UDP: 5060 -> 17973

eth1.10:o[398]: w.x.y.z -> a.b.c.d (UDP) len=398 id=5495

UDP: 5060 -> 17973

eth1.10:O[398]: w.x.y.z -> a.b.c.d (UDP) len=398 id=5495

UDP: 5060 -> 17973

As it can be seen the reply does not get translated back as it should to destination port 5060 and thus will not be accepted by the asterisk box.

To understand and be able to solve the current dilemma its imperative that we explore why the Checkpoint Firewall is behaving this way and preventing our Asterisk box from registering the SIP trunk.

The Stateful Inspection Technology implements all the necessary firewall capabilities at the network level. The FireWall-1 Inspection Module accesses and analyzes data derived from all communication layers. The FireWall-1 Security Server enables the system administrator to define a Security Policy on a per-user basis.

The Inspection Module is located between the Data Link (IP-Stack) and Network Layer (Device Driver). Authentication and Content Security are provided by a suite of FireWall-1 Security Servers, running at the application layers.


The Security Servers enforce Content Security and Authentication for a particular service. Defining a protocol type within an associated service invokes specific protocol handlers enabling a higher level of security by parsing the protocol, and a higher level of connectivity by tracking dynamic actions and these checks are mostly overridden by SmartDefense checks.

So to recap. As the data moves up the OSI layers, it can be intercepted by both the Security Servers and SmartDefense. In this particular case the protocol definition which invokes specific protocol handlers are modifying the reply SIP packets during translation using a random port and not the UDP 5060 asterisk is expecting.

Modifying the Protocol Type on the udp-sip service under the “Advance UDP Services Properties” from SIP_UDP to None will solve the issue.

[ad]

Checkpoint Firewall-1 Upgrade NG-R55 to NGX-R65

This will undoubtedly be a fun and tedious challenge. No support and only Google to work with.

The upgrade will consist of upgrading from a clone PC with 3 NIC cards running Secure Platform NG R55 to Secure Platform NGX R65running on a Dell PowerEdge 1950 with 2 x 146Gb 15K rpm drives and 4 NIC cards.

A lot of research went into the actual migration and during this research I found an excellent summary on backups, snapshots and upgrade exports.

[Oversimplified Executive Summary]
  • -A upgrade_export contains just Check Point configuration
  • -A backup is an upgrade_export plus SPLAT OS configuration
  • -A snapshot is a backup plus binary files, both Check Point and SPLAT OS
  • -As a general rule of thumb, if your restoring on the same hardware a snapshot would be the easiest to use since it contains the most info and an upgrade_export would be the worst, since you’d have to manually restore the most stuff.
[upgrade_export]
  • -It doesn’t backup any OS (i.e. SPLAT) settings, it only backup up CheckPoint settings
  • -It will let you export on one OS and then import on a different OS (i.e. go from Windows to SPLAT)
  • -You can upgrade_import on different hardware (i.e. go from IBM to HP)
  • -You can restore an export from an older version to a newer version of CheckPoint. A SPLAT backup/restore requires that you have the exact same versions. Note that when upgrading from an older to newer version, you must use the newer version’s upgrade_export utility to create the export file.
  • -It restores the product list as well. The SPLAT restore command won’t restore the Check Point settings if you don’t have the exact same products (and product versions) installed.
[backup]
  • -A SPLAT backup will back up both the SPLAT OS settings as well as the CheckPoint settings
  • -Basically it’s an upgrade_export with OS settings added in
  • -Restoring a backup file requires the exact same software installation. I.e. you can’t restore a backup from R55 on to R60 (the HFA level must match as well). The installed product list must match as well. Note that you can still restore the OS settings even if your installed Check Point product list doesn’t match.
  • -The SPLAT OS settings are hardware specific. If you restore the system settings you must restore on the same hardware. However, if you only restore the Check Point settings you can restore on different hardware. Restoring just the Check Point settings is essentially the same thing as doing an “upgrade_import” of an exported file.
[snapshot]
  • -A snapshot is even better than a backup since it contains binary files. I.e. you can revert from R60 to R55 with a snapshot. The downside to this is that a snapshot file is much larger than an upgrade_export or backup file.
  • -A snapshot can also roll you forward for minor software changes. For example if I revert from R60 HFA05 to HFA01 I can later revert back to R60 HFA05 from R60 HFA01
  • -A snapshot cannot revert to a newer major release of Check Point. I.e. you can’t revert from R55 to R60.
  • -If you’re reinstalling SPLAT on the same hardware you don’t have to install any HFA’s or change any configuration. Simply reverting to your saved snapshot file will restore all configurations and HFAs. The only stipulation is that the major software version must match. I.e. a R60 snapshot file will only work on a R60 install (regardless of HFA level).
  • -You can only revert on the same hardware, since the snapshot file contains hardware specific SPLAT settings.
[An exception to the rules]
  • -If you’re feeling lucky I’ve noticed that you can actually restore a backup file or snapshot file on different hardware as long as you:
  • -Delete “/etc/sysconfig/hwconf” (this is automatically re-created during the reboot)
  • -In the case of a snapshot file also delete “/etc/modules.conf”
                -Backups don't contain this file
                -modules.conf controls which drivers are loaded
                -This is be automatically re-created during the reboot
  • -Remove the “hwaddr” lines from /etc/sysconfig/netconf.C
  • -Reboot
  • -You must remove the hwaddr lines since the firewall will use the MAC addresses stored in the snapshot/backup file, not your network card’s physical MAC addresses. You can verify which MAC addresses you’re using with these commands:
        ifconfig |grep HWaddr
                -This shows which MACs you're currently using
        grep hwaddr /etc/sysconfig/hwconf
                -This should contains your NICs' physical MAC addresses.
           If in doubt, delete this file, reboot and this file will be
           automatically created on startup.
        grep hwaddr /etc/sysconfig/netconf.C
                -This shows which MACs your server is configured to use.
           If there are no "hwaddr" lines, then your NIC's physical MACs
        will be used.  If there are no "hwaddr" lines you can create them
        by running "cpnetconf store".
  • -To remove the hwaddr lines in “/etc/sysconfig/netconf.C” run these commands:
        cd /etc/sysconfig
        cpstop
        mv netconf.C netconf.C.old
        grep -v hwaddr netconf.C.old >netconf.C
        rm /etc/sysconfig/hwconf
        reboot

Instructions:
  1. Make a backup, a snapshot of your original firewall. Its not fun having to restore a firewall from scratch without a backup.
  2. Make a note of the DNS servers, IP addresses and associated ethernet NICs (ie. eth0, eth1, eth2, etc.), make a note of products installed.
  3. Secure an Eval license from a Checkpoint vendor.
  4. Install the new version of Checkpoint on the new hardware.
  5. cd to $FWDIR/bin/upgrade_tools and run “./upgrade_export /path/with_enough_space/cpexport_R55.tgz” on the production firewall.
  6. Download the upgrade_checker from Checkpoint depending on your upgarde path. In my case its R65_upgrade_checker.linux22.tgz
  7. Extract the checker and run the R65 version of the upgrade_export binary. “./upgrade_export /path/with_enough_space/cpexport_R65.tgz”
  8. Import both exports into your new firewall.  1st the R55 export and then the R65 export. Run “./upgrade_import cpexport_R55.tgz” and then “./upgrade_import cpexport_R65.tgz”.
  9. Be sure to upgrade your license. You will need internet connectivity and an active support agreement with Checpoint. The file that you need to run is in the NGX CD and its called <OS>/license_upgrade. Run “./license_upgrade simulate” and then “./license_upgrade upgrade”. You can check the status by isung the status flag.

[ad]