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
- Forcing the nodename IP
- Touching all putkey-related files
- Flushing all putkey-related files
- If you don't want to fwstop the firewall module
- As A Last Resort
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:
- fwstop both the management and firewall modules
- On the FireWall, type: fw putkey 172.31.0.42
- On the management console, type: fw putkey 153.1.214.10 192.168.0.10
172.16.0.10 10.0.0.10
- fwstart the management console
- 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:
- fwstop both the management and firewall modules
- On the FireWall, type: fw putkey -n 172.16.0.10 172.16.10.42
- On the management console, type: fw putkey -n 172.16.10.42 172.16.0.10
- fwstart the management console
- 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.