Firewall Wizards mailing list archives

Re: Lost DH-key


From: "Sean Costello" <Xlate () iname com>
Date: Fri, 4 Feb 2000 00:53:33 -0600

Joe wrote:

I have had this happen twice now so it is time to query the group with it.
When using skip-method VPN's renaming of a remote firewall object on a
FW-1
management server results in apparently irrecoverable loss of the
Diffe-Hellman key.  I do this once in awhile when moving a firewall from
one
city to another or to bring the object name up to company standards.

Anyone out there ever recover a lost FW-1 DH key?

In this instance either "renaming" means creating a new Objects.C entry
without copying all of it's properties, or you are renaming the object to a
name already in use by another object.  Even if it's been "deleted" since
the entry isn't ever actually removed from the $FWDIR/conf/objects .C

In the former scenerio it means that once you recreate the DH key it is
store in the raw inside the objects.C as one of the defined workstation's
properties and the problem is resolved.  You might be able to back this up
but I'm unsure as to whether or not it's enough for restoration.

The cause is due to an inherant problem with FW-1's ability to properly
locate the DH key of any machine in the objects.C whenever there are
multiple occurances of the name.

If there are multiple entries and you regenerate the DH key who's to say it
wouldn't work even if it's confused about the proper location.

Another manifestation of this issue is also documented in an FAQ on CP's
website regarding the mgmt. servers inability to properly locate the DH key
with duplicate entries during the Skip key exchange although I can't seem to
locate the link at this time.

This is consistant with the possibility that even though the DH key is
stored in the raw in the objects.C file.  It's entirely possible that the
firewall is getting the DH key from another location.  If the duplicate
object wasn't also defined as a firewall then you would never query for the
objects DH Key property.  So you might never notice the inconcistancy until
modifying the objects  name.

On a side note this also means that updates to the objects.C file are
runtime thus possibly affecting production services when using VPN's.
Remember to always backup key files even when you're just making
modifications to objects through the GUI before you save them.

Ultimately I would say that you might want to consider creating the generic
or common network objects in a clean install of FW-1.   Then using the fw
confmerge command to import the objects.C created into each new
installation.  Also, remembering to follow object naming guidlines.

hope this helps...

Sean Costello
xlate () iname com




Current thread: