Checkpoint Firewall Upgrade from R67 VSX to R77.10 VS & CIFS Resources

I have some Crossbeam X80 hardware running R67 VSX for some virtual firewalls.  Life is good and everything worked fine.  I planned and executed an upgrade plan for these blades to move to Checkpoint R77.10 VS.  The policy upgrade process and software upgrade process went with zero errors.  When we tried to push the policy to the firewalls, it would fail.  The errors, during a debug, were ambiguous at best.

What was the eventual issue?  CIFS Resources with greater then 25 file shares.  It seems the IPS in R77 has a hard limit of 25 shares in CIFS resources.  We use CIFS resources as an extra level of protection when 3rd Parties access our Windows File Shares.

Most of our CIFS resources had less then 25 file shares, so they needed no change.  But, a single 3rd party accessed quite a few shares.  So, the revert back to a straight CIFS service group on these rules and removal of the CIFS resource in the firewall policy allowed a successful push of the policy to the gateway.

NOTE TO SELF: Keep that one in your back pocket.

Checkpoint Firewall: SecureXL and PPPoE do not play well

I recently had to upgrade an R70 Checkpoint firewall to R77.10.  Due to a variety of issues, this required a nuke and rebuild of the firewall via USB key to upgrade to R77.10.

The upgrade went fine, but during testing the firewall passed no traffic. This was an unusual config, the internet service was a PPPoE connection.

After a fair amount of troubleshooting went into this problem.  It wasn’t until a fw ctl zdebug -m fw + drop  command was run that the problem become obvious.  The following error was displayed:

;[fw4_0];fw_log_drop_ex: Packet proto=6 -> dropped by cphwd_offload_conn Reason: VPN and/or NAT traffic between accelerated and non-accelerated interfaces or between non-accelerated interfaces is not allowed;

A quick look on Checkpoint’s Support Site gave us Solution ID: sk79880.


Kernel debug shows (fw ctl zdebug -m fw + drop) that traffic is dropped:

‘… is dropped by cphwd_offload_conn Reason: VPN and/or NAT traffic between accelerated and non-accelerated interfaces or between non-accelerated interfaces is not allowed’


No fix is required; the system is functioning as designed.

SecureXL does not support Point-to-Point interfaces (PPP, PPTP, PPPoE). In case a PPP-interface is detected, SecureXL disables itself on that interface (hence the name ‘non-accelerated interface’).

Refer to the following note in any ‘Performance Pack Administration Guide’ (R65, R70, R71, R75, R75.20, R75.40, R75.40VS, R76):

Note: Performance Pack is automatically disabled on PPTP and PPPoE interfaces.

If a connection is detected, which flows through even one such non-accelerated interface, and this connection is NATed and/or sent over VPN, it will be dropped, because SecureXL is not able to handle it: because of NAT (Client Side or Server Side) and/or VPN, some connection parameters are not available – SecureXL is not able to determine how to pass such connection.


Possible steps:

  1. Change the rulebase, so that the problematic connection is not sent through such non-accelerated interface(s).
  2. Disable NAT on the problematic connection.
  3. Change the rulebase, so that the problematic connection is not sent over VPN.
  4. Disable SecureXL completely (via ‘fwaccel off’ command and via ‘cpconfig’ menu).

We disabled SecureXL and had no problems since.



Cisco Router to Checkpoint FW-1 — IPSEC VPN Headaches with Supernetting

I setup quite a few IPSEC site-to-site VPNs.  Hundreds maybe.  Most go fine.  10 minutes on the line, bing, bam boom, we have a working IPSEC tunnel.

My company uses Cisco router/ASRs for our termination points for IPSEC VPNs.  We also have Checkpoint firewalls doing the filtering.  Why the separation?  Because we love a good headache.

My biggest headache comes from when a third party is using a Checkpoint firewall as the VPN termination point and I am using my Cisco router.  Checkpoint firewalls, often by default, will super-net the encryption domain.  So, I might be using a /32 host ACL on my Cisco, the Checkpoint is sending a /24 or larger ACL.  This does not play well in Cisco land and Phase 2 usually fails.

The hard part with this is figuring out this is happening, because it’s not obvious.  What I have found is turning on a single debug command makes all the difference in the world.

debug crypto ipsec

This shows all kinds of nasty IPSEC messages when a tunnel is negotiating.  You try finding the error on a box that has 75 tunnels terminating on it.  It is not easy! But, as the debug messages are scrolling by, one little entry can give you all the help you need:

Feb 1 17:20:39: Crypto mapdb : proxy_match
src addr :
dst addr :
protocol : 0
src port : 0
dst port : 0

On this particular tunnel (IPs changed to protect the innocent) the third party was supposed to be NATing behind a /32 address on the network.  But, his Checkpoint box was super-netting behind the /25 network.  Bad Checkpoint.

I was able to pick it up from that debug message and let him know to change his config.  Five minutes later, IPSEC tunnel was up, Phase 1 and Phase 2 setup and communication was clean.


How to configure a Checkpoint UTM device without using the GUI

There is an annoying aspect of configuring a Checkpoint UTM appliance, you are forced to enter the web based GUI to do some basic config before using the command line interface (CLI) to complete the install.  If you try to use the CLI before using the GUI, you receive the following message:

Welcome to VPN-1 UTM Appliance

You can not use the ‘sysconfig’ and ‘cpconfig’ utilities until you successfully complete the First Time Wizard in the Administration web GUI.

Press Enter to continue…

If you run the following command, this message is not displayed and you can use the CLI for the full config:

  • SecurePlatform OS:
  • Gaia OS:


How to configure DNS NAT or DNS Doctoring on Checkpoint FW-1

In some topologies, it is required to DNS reply traffic from a DNS server so that the querying host will think that a certain DNS entry (example is resolvable to a different IP address than the one written in the database of the DNS server.

The feature has a global on/off switch, in the objects_5_.C file, called fw_dns_xlation (by default set to false). When it is set to true, the regular NAT Rule Base is used to determine how to change the DNS packets.
The regular NAT rules used to NAT the internal servers will suffice. There is no need to define special NAT rules in addition to the regular ones defined.

To enable the fw_dns_xlation property, perform on the SmartCenter server:

  1. Close all SmartConsole clients connected to the SmartCenter server.
  2. Open the GuiDBedit utility and and connect to the SmartCenter server.
  3. Find the fw_dns_xlation property.
  4. Change the value of this property to true. Click OK.
  5. Select File -> Save All.
  6. Open the SmartDashboard and re-install the Security Policy on the Security gateway.

From this point on, the Security gateway will NAT the DNS data, according to the NAT Rule Base.
You must also enable the DNS protocol protection for UDP in the IPS (formerly, SmartDefense). To enable this protection:

For the Security Gateway R70:

  1. Open the IPS tab in the SmartDashboard.
  2. Go to the Protections -> By Protocol -> Application Intelligence -> DNS view.
  3. Open the ‘DNS – General Settings’ Protection Details.
  4. Click Edit.
  5. Verify that either the ‘UDP only’ or ‘Both TCP and UDP’ checkbox is selected.

For all other versions:

  1. Open the SmartDefense tab in the SmartDashboard.
  2. Go to the Application Intelligence -> DNS -> Protocol Enforcement view.
  3. Verify that the ‘UDP protocol enforcement’ checkbox is selected.


  1. The manual rules for network objects or Automatic NAT Static rules for host objects must be used. This feature does not work with Automatic NAT Static rules of network objects.
  2. Traffic will be modified based on the destination address of the NAT rules without considering the source of the traffic.
  3. The feature does not work for a DNS zone transfer (used to synchronize DNS databases between to internal DNS servers).
  4. The feature does not work for DNS queries over TCP.
  5. The Security gateway must be between the querying host and the DNS server.
  6. On Security Gateway R70, DNS traffic cannot be accelerated when using this feature.

If the “NAT for DNS payload” option is enabled and the “UDP DNS protocol enforcement” protection is disabled on at least one of SmartDefense/IPS profiles, the Security Policy installation will succeed but the following warning will appear:
“You enabled NAT on DNS payload, please make sure that DNS UDP protocol enforcement defense is enabled on the desired gateway.”