Blast from the CHKP Past: Can't Get Putkeys to Work

For those of you who never had to work with Check Point FireWall-1 4.1 and earlier, you're lucky you likely never EVER had to use putkeys.

The fw putkey was used to establish authentication between the Management and Firewall modules. The problem was: the authentication would frequently break. Especially in larger, distributed environments. Often for reasons that no one outside of a few developers in Tel Aviv never fully understood.

The eventual replacement for fw putkey was SIC, which was added in FireWall-1 NG (5.0). It is based on certificates and is way easier to set up. It's also far less prone to random breakage. 

The following classic article is presented for nostalgia purposes only. Hopefully no one in their right mind still needs this article, which was very popular on my FireWall-1 FAQ back in the day. It was the collective wisdom of my peers and my own experience as of around 2000 or so.

Can't Get Putkeys to Work

Q:

I can't get my putkeys to work ir I can't keep them working. What am I doing wrong?

A:

One thing that I've always done on habit with my firewall systems is to make sure all IPs on both the management and firewall are resolvable to a hostname within the system's local host file and that the systems are configured to look at the local hosts file before looking to DNS. As a result, the number of issues I personally have had with putkeys in any systems I have personally set up have been minimal. I would suggest doing this before redoing all your putkeys. Also, double-check to make sure the time on your management console and firewall module have their time synchronized (relative to GMT).

One known issue: If you are using skey authentication on versions of FireWall-1 prior to 4.0 SP5, there is an issue whereby the authentication can get out of sync. Either use fwn1 (which works on systems 4.0 SP4 and earlier) or use none authentication. For more information, see: Failed to Install Security Policy on fw62bs01: Unauthorized action.

If you have to redo your putkeys, there are three methods one can use to do putkeys, one of which usually works:

Putkey with all IPs

A trick I have found that works is to use all possible IP addresses in a putkey command. For example, if my management console had only one IP (172.31.0.42) and my firewall had several IPs:

le0: 153.1.214.10
qe0: 192.168.0.10
qe1: 172.16.0.10
qe2: 10.0.0.10

My putkey from the management console to the firewall would look like this:

fw putkey 153.1.214.10 192.168.0.10 172.16.0.10 10.0.0.10

And my putkey from the firewall to the management console would be:

fw putkey 172.31.0.42

In a step-by-step manner, here is what you would do:

  1. fwstop both the management and firewall modules
    2.  
  2. On the FireWall, type: fw putkey 172.31.0.42
    3.  
  3. On the management console, type: fw putkey 153.1.214.10 192.168.0.10 172.16.0.10 10.0.0.10

  4. fwstart the management console
    5.  
  5. fwstart the firewall module

Forcing the nodename IP

When performing the authentication necessary for remote management, FireWall-1 will attempt to use the 'nodename IP' to communicate between the systems. If the nodename IP does not exist or is not reachable from all systems, this causes putkeys to not work. A way to get around this problem is to use putkey in the following manner:

fw putkey -n local-ip remote-ip

The "local ip" here depends on which interface you will need to talk out to see the remote system. The "remote ip" will be the IP address that is closest to you.

For instance, if your firewall had the following interfaces:

le0: 153.1.214.10
qe0: 192.168.0.10
qe1: 172.16.0.10
qe2: 10.0.0.10

And your management console had the following interfaces:

le0: 172.16.10.42

On the firewall console, you would type:

fw putkey -n 172.16.0.10 172.16.10.42

On the management console, you would type:

fw putkey -n 172.16.10.42 172.16.0.10

In a step-by-step manner, here is what you would do:

  1. fwstop both the management and firewall modules
  2. On the FireWall, type: fw putkey -n 172.16.0.10 172.16.10.42
  3. On the management console, type: fw putkey -n 172.16.10.42 172.16.0.10
  4. fwstart the management console
  5. fwstart the firewall module

Touching all putkey-related files

Karim Ismail makes the following suggestion: Simply "touch" the following files (i.e. use the Unix/IPSO "touch" command) before performing the putkey command:

$FWDIR/conf/fwauth.keys
$FWDIR/conf/serverkeys.*
$FWDIR/database/authkeys.C
$FWDIR/database/opsec_authkeys.C

The control.map file

Sometimes, you will need to add IP addresses to $FWDIR/lib/control.map because, for whatever reason, FireWall-1 is not seeing the IP address it is hearing the connection from as the appropriate type of host (either as a remote firewall module or a management console). In any case, you can insure that FireWall-1 is handling this correctly by editing $FWDIR/lib/control.map. Add all the IPs of the remote hosts you wish to authenticate with in a new line (above the MASTERS, CLIENT, and * lines) and force the authentication that will be used for these IPs to the appropriate authentication scheme (fwn1, fwa1, skey).

a.b.c.d, e.f.g.h : */fwa1
MASTERS :stat,getkey,gettopo/none opsec/fwn1 */fwa1
CLIENT  :load,db_download,fetch,log/fwa1   opsec/fwn1 */none
*       :stat,getkey,gettopo/none unload,ioctl,load,db_download/deny opsec/fwn1 */fwa1

If you edit this file, stop and start FireWall-1. For more information  on control.map, see: Failed to Install Security Policy on fw62bs01: Unauthorized action

Flushing All Putkey-Related Files

There are some cases where even this does not work. Here is a procedure developed by Lance Spitzner (which I have slightly modified):

On the Management Module

  •  fwstop
  •  Backup the following files by copying them to <filename>.old
    • $FWDIR/database/authkeys.C
    • $FWDIR/database/opsec_authkeys.C
    • $FWDIR/conf/fwauth.keys
    • $FWDIR/conf/serverkeys.*
  • Remove the above files
  • Confirm that $FWDIR/lib/control.map is using the same authentication as the remote modules (fwa1 or skey).
  • Make sure /etc/hosts has an entry for the remote module(s).
On the Remote Module
  • fwstop
  • Backup the following files by copying them to <filename>.old
    • $FWDIR/database/authkeys.C
    • $FWDIR/database/opsec_authkeys.C
    • $FWDIR/conf/fwauth.keys
    • $FWDIR/conf/serverkeys.*
  • Remove the above files
  • Confirm that $FWDIR/lib/control.map is using the same authentication as the management module (fwa1 or skey).
  • Make sure /etc/hosts has an entry for the management module.
On the Management Module: fw putkey -p <password> -n <local IP> <remote IP>

On the Remote Module: fw putkey -p <password> -n <local IP> <remote IP>

On the Mangement Module: fwstart

On the Remote Module: fwstart

That's it!  If that did not do the trick, ensure all Network Objects in Rule Base match /etc/hosts file and fw putkey IP addresses.  Repeat steps above.

If you don't want to fwstop the firewall modules

I personally have had success sometimes simply killing and restarting fwd, which is not as drastic as restarting FireWall-1, but can make certain services unavailable. However, Bradley Filmer says this method does not require fwstopping the firewall module.

On the firewall module, edit $FWDIR/database/authkeys.C and remove everything between the opening parenthesis "(" and the closing parenthesis ")". Redo the putkeys using one of the methods above (he suggests using the -n method, but only use that method if you have to). On the management console, do the same thing except perform an fwstop and fwstart afterwords.

As a Last Resort

Sometimes, you will need to reboot either the management console, firewall module, or both to make putkeys work. Don't necessarily have an explanation for it. If you reboot one but not the other, execute an fwstop; fwstart on the other box.

Even after that, it may not work either. What you can do is disable putkey authentication entirely. Note that this is not entirely recommended in all cases, but if you need to get it working quickly, this trick will definately work. Edit control.map as above on all involved systems and use "none" as the authentication scheme. Stop and start FireWall-1. You will no longer have any more troubles with putkeys between these systems as you have effectively reduced the authentication to IP only.