FWVPN

Virtual Private Networking
with Check Point

FireWall-1™
Version 4.0
Part No.: 71300007400

September 1998
© Copyright 1994–1998 Check Point Software Technologies Copyright © 1996-1998. Internet Security Systems, Inc. All Rights Reserved.
Ltd. RealSecure, SAFEsuite, Intranet Scanner, Internet Scanner, Firewall Scanner,
and Web Scanner are trademarks or registered trademarks of Internet Security
All rights reserved. This product and related documentation are protected by Systems, Inc.
copyright and distributed under licensing restricting their use, copying, distribu-
Copyright © Sax Software (terminal emulation only).
tion, and decompilation. No part of this product or related documentation may be
reproduced in any form or by any means without prior written authorization of The following statements refer to those portions of the software copyright-
Check Point. While every precaution has been taken in the preparation of this ed by Carnegie Mellon University.
book, Check Point assumes no responsibility for errors or omissions. This publi- Copyright 1997 by Carnegie Mellon University. All Rights Reserved.
cation and features described herein are subject to change without notice. Permission to use, copy, modify, and distribute this software and its documenta-
tion for any purpose and without fee is hereby granted, provided that the above
RESTRICTED RIGHTS LEGEND: copyright notice appear in all copies and that both that copyright notice and this
Use, duplication, or disclosure by the government is subject to restrictions as set permission notice appear in supporting documentation, and that the name of
forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Soft- CMU not be used in advertising or publicity pertaining to distribution of the soft-
ware clause at DFARS 252.227-7013 and FAR 52.227-19. ware without specific, written prior permission.
CMU DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, IN-
TRADEMARKS: CLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS,
Check Point, the Check Point logo, FireWall-1, FireWall-First!, FloodGate-1, IN NO EVENT SHALL CMU BE LIABLE FOR ANY SPECIAL, INDIRECT OR
INSPECT, IQ Engine, Open Security Manager, OPSEC, SecuRemote, UAP, CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING
VPN-1 and ConnectControl are registered trademarks or trademarks of Check FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
Point Software Technologies Ltd. CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFT-
All other product names mentioned herein are trademarks of their respective WARE.
owners.
The products described in this document are protected by U.S. patent no.
5,606,668 and may be protected by other U.S. patents, foreign patents, or pend-
ing applications.
THIRD PARTIES:
Entrust is a registered trademark of Entrust Technologies, Inc. in the United
States and other countries. Entrust’s logos and Entrust product and service
names are also trademarks of Entrust Technologies, Inc. Entrust Technologies
Limited is a wholly owned subsidiary of Entrust Technologies, Inc. FireWall-1 and
SecuRemote incorporate certificate management technology from Entrust.
The following statements refer to those portions of the software copyright-
ed by University of Michigan.
Portions of the software copyright © 1992-1996 Regents of the University of
Michigan. All rights reserved. Redistribution and use in source and binary forms
are permitted provided that this notice is preserved and that due credit is given to
the University of Michigan at Ann Arbor. The name of the University may not be
used to endorse or promote products derived from this software without specific
prior written permission. This software is provided “as is” without express or im-
plied warranty.
Check Point Software Technologies Ltd.

International Headquarters: U.S. Headquarters:
3A Jabotinsky Street Three Lagoon Drive, Suite 400
Ramat Gan 52520, Israel Redwood City, CA 94065
Tel: 972-3-753 4555 Tel: 800-429-4391 ; (650) 628-2000
Fax: 972-3-575 9256 Fax: (650) 654-4233
August 12, 1998
e-mail: info@CheckPoint.com http://www.checkpoint.com
Please direct all comments regarding this publication to techwriters@checkpoint.com.
Please
Recycle
Contents
Preface xiii Certificate Authorities 5
Scope xiii Encryption Schemes 5
Who Should Use this User Guide xiv Elements of an Encryption Scheme 5
Summary of Contents xiv Encryption Schemes Supported by

FireWall-1 6
What Typographic Changes Mean xv
FWZ (FireWall-1) Encryption Scheme 7
Shell Prompts in Command Examples xv
Manual IPSec Encryption Scheme 8
Encryption 8
1. Introduction 1
Tunnel Mode 8
Encryption Technology 1
Authentication 9
Basic Definitions 1
Shortcomings 9
Encryption 1
SKIP Encryption Scheme 9
Authentication 1
ISAKMP/OAKLEY Encryption Scheme 10
Encrypting a Message 2
ISAKMP Phase One (Main/Aggressive
Sharing a Secret Key 2 Mode) 10
Public Key Distribution System 2 ISAKMP Phase Two (Quick Mode) 10
Diffie-Hellman Scheme 3 Comparison of Encryption Schemes 11
RSA Public Keys 4 SecuRemote 11
Digital Signatures 4 Overview 11
Generating a Digital Signature 4 Additional Information 13
Verifying a Digital Signature 4
Certificates 5
Contents i
2. Configuring FireWall-1 Encryption 15 ▼ Actions Performed by Alice on Receipt of
Bob’s Reply 34
FireWall-1 Encryption — Overview 15
Extended Encryption Protocol (Automatic Key
Encryption Domains 16 Update) 34
Key Management 16
Configuration Examples 17 3. Encryption Properties 35
Specifying Encryption 17 Encryption Properties 35
A Two Gateway Configuration (FWZ) 17 Properties Setup - Encryption 36
Adding an Encryption Rule to a Rule SecuRemote 36

Base 22 Manual IPSec 37
Virtual Encryption Session (FWZ) 23 SKIP 37
FWZ Key Hierarchy 24
ISAKMP Key Renegotiation 38
A Two Gateway Configuration (Manual
Properties Setup - Logging and Alerting 38
IPSec) 24
Workstation Encryption Properties 39
A Two Gateway Configuration (SKIP) 25
OpenLook GUI 40
A Two Gateway Configuration
(ISAKMP/OAKLEY) 26 Windows GUI 41
Both Gateways FireWalled 26 Encryption Setup 41

Only One Gateway FireWalled 28 OpenLook 42
A Three Gateway Configuration 29 Windows 42
Encrypting Communications with External Encryption Setup — ISAKMP/OAKLEY 43
Networks 30
Shared Secrets 44
Configuring the “Local” Network 30
Public Key Infrastructure 45
Configuring the “Remote” Network 32
Public Key Configuration 45
When Keys Change 32
Encryption Setup — SKIP 47
Internal Encryption 32 OpenLook GUI 47
FWZ Encryption Protocol — Detailed Additional SKIP Properties 48
Description 32
Windows GUI - CA Key Tab 49
Introduction 32
Windows GUI - DH Key Tab 50
Basic Encryption (Session Key Exchange)
Protocol 33 Additional SKIP Properties 50
▼ Actions Performed by Alice 33 Encryption Setup — Manual IPSec 51
▼ Actions Performed by Bob 33 Encryption Setup — FWZ 52

OpenLook GUI 52
ii Virtual Private Networking with FireWall-1 • September 1998

Windows GUI - CA Key Tab 53 New Keys 71
Windows GUI - DH Key Tab 54 Encrypting Services That Open Back
Connections 71
Windows GUI - Encapsulation Tab 55
Key Info (FWZ and SKIP) 56
4. SecuRemote Server 73
User Encryption Properties 56
SecuRemote Implementation 73
Windows GUI 56
Overview 73
OpenLook GUI 57
Example 74
ISAKMP Properties 58
Before SecuRemote is Installed 74
Authentication Tab (Windows GUI) 59 After SecuRemote is Installed 75
Encryption Tab (Windows GUI) 59 Defining SecuRemote Users 77
FWZ Properties 60 Windows GUI 77
Rule Encryption Properties 61 FWZ Authentication Properties 78
Windows GUI 61 Encryption Properties 79
OpenLook GUI 61 FWZ Properties 79
ISAKMP/OAKLEY Encryption Properties 62 ISAKMP Properties 80
SKIP Encryption Properties 63 OpenLook GUI 80
Manual IPSec Encryption Properties 65 FWZ Authentication Properties 81
Defining an SPI (OpenLook) 66 Encryption Properties 82
Defining an SPI (Windows) 66 Structure of a SecuRemote Connection 82
Creating a New Key 67 Topology 82
Deleting a Key 67 Topology Download 83
Modifying a Key 67 Authentication 84
▼ To generate a key from a seed 68 Encryption Method 84
OpenLook GUI 68 Authentication Methods 85
Windows GUI 68 FWZ 85
▼ To generate a key manually 68 ISAKMP 85
OpenLook GUI 68 Key Exchange 86
Windows GUI 68 Connection 86
FWZ Encryption Properties 69 Routing 86
Certificate Authority (FWZ Encryption) 70 Step by Step Example 86
Overview 70 Configuring the Network 86
Contents iii
Defining Users 87 SecuRemote Daemon 104
Rule Base 88 When the SecuRemote Kernel Module
Starts 104
Destination 90
When the SecuRemote Daemon Starts 105
Other FireWalls 91
As the User Works 105
Services 91
Installing the SecuRemote Client 105
Address Translation 91
Minimum Installation Requirements 105
Current Restrictions 91
Installation Procedure 106
VPN Configuration 91
Uninstalling the SecuRemote Client 108
Control Properties (Properties Setup) 92
▼ To uninstall the SecuRemote
FTP 92
Client 108
RealAudio 92
After Installing 109
VDOLive 92
Removing or Moving the SecuRemote
RPC 92 Files 109
Known Restrictions 93 Modifying the Network Configuration 109
Timeout 93 Multiple adapters 109
Data Not Encrypted 93 Removing the FW-1 adapter 110
TCP Stacks 93 To remove the FW-1 adapters 110
User Password 93 Removing More than One Adapter 110
FireWall-1 Adapters 93 Using the SecuRemote Client 111
Power Management 94 Defining Sites 111
Modifying the Network Configuration after Adding a Site 112
Installing SecuRemote 94
▼ To add a new site 112
FWZ Encapsulation 94
Viewing Sites 114
How FWZ Encapsulation Works 95
Deleting a Site 114
Implementing Encapsulation 97
▼ To delete a site 114
DNS 97
Properties 114
Example 99
▼ To view a site’s properties 114
SecuRemote Error Messages 101
Authentication 116
5. SecuRemote Client 103 Encryption Method 116
SecuRemote Client 103 Authentication Methods 117
SecuRemote Kernel Module 103 FWZ 117
iv Virtual Private Networking with FireWall-1 • September 1998

ISAKMP 117 SecuRemote Client Toolbar 130
Password Window (FWZ Authentication) 118
6. Troubleshooting 131
User Authentication 119
General Troubleshooting Procedures 131
Options 120
Preventing Common Problems 131
Options window 120
IPSec and ISAKMP 131
Erasing Passwords 121
Unix 131
Password Expiration 121
NT 131
Entering a Password Before the Connection
Begins 122 SKIP 132
Certificates 122 Examining the Log 132
ENTRUST.INI File 122 Configuration 133
Entrust Users 123 Encryption Error Messages 133
Creating a Profile 123 Basic Encryption Protocol 133
Recovering a User 123 Errors Reported by Alice (Encrypting
Properties 124 Gateway) 133
Closing the SecuRemote Daemon 125 Errors Reported by Bob (Decrypting

Gateway) 136
Single SignOn 125
Extended Encryption Protocol (FWZ
Overview 125 only) 140
Configuring Single SignOn 125 Fetching Keys from a Remote Certificate
Authority 140
Disabling Single SignOn 126
Troubleshooting SecuRemote 142
SecuRemote Client Menus 127
Installation 142
File Menu 127
Routing 143
View Menu 127
No SecuRemote Server Along Route 143
Sites Menu 128
Password Dialog Box 143
Password Menu 128
Service Cannot be Accessed 144
Tools Menu 128
Data Not Encrypted 145
Entrust Menu 129
Help Menu 129 Master Index Index-i
Contents v
vi Virtual Private Networking with FireWall-1 • September 1998
Figures
FIGURE 1-1 Encrypting and then decrypting with a FIGURE 2-10 Network Configuration with External
secret key restores the original Encrypting Gateway 31
message 2
FIGURE 3-1 Properties Setup — Encryption
FIGURE 1-2 Agreeing on a Secret Key by tab 37
exchanging the public parts of
Diffie-Hellman keys 3 FIGURE 3-2 Properties Setup — Logging and
Alerting tab 38
FIGURE 1-3 Virtual Private Network with a nomadic
SecuRemote Client 12 FIGURE 3-3 Workstation Properties window
(OpenLook) and Encryption tab of
FIGURE 2-1 Two Gateway Network Workstation Properties window
Configuration 16 (Windows) 40
FIGURE 2-2 Workstation Properties for an FIGURE 3-4 ISAKMP Properties window and
encrypting gateway (OpenLook and Encryption Setup (ISAKMP)
Windows) 18 window 43
FIGURE 2-3 Encryption Setup window — before a FIGURE 3-5 ISAKMP Shared Secrets window 44
key has been generated 19
FIGURE 3-6 Entering a Pre-Shared Secret 44
FIGURE 2-4 FWZ Properties window — after a key
has been generated 20 FIGURE 3-7 Shared Secrets window showing a pre-
shared secret 45
FIGURE 2-5 A gateway’s public key
(OpenLook) 20 FIGURE 3-8 ISAKMP Public Key Configuration
window 45
FIGURE 2-6 Encryption Properties window 21
FIGURE 3-9 Generate Key window 46
FIGURE 2-7 ISAKMP Properties window and
Encryption Setup (ISAKMP) FIGURE 3-10 Encryption Setup window — SKIP
window 27 (OpenLook) 47
FIGURE 2-8 ISAKMP Properties window 28 FIGURE 3-11 SKIP Properties window - CA Key
tab 49
FIGURE 2-9 Three Gateway Network
Configuration 29
Figures vii
FIGURE 3-12 SKIP Properties window - DH Key FIGURE 4-4 User Properties window —
tab 50 Authentication tab showing S/key
Authentication 78
FIGURE 3-13 Encryption Setup window — IPSec
(OpenLook) 51 FIGURE 4-5 User Properties window — Encryption
tab 79
FIGURE 3-14 Encryption Setup window — FWZ
(OpenLook) 52 FIGURE 4-6 FWZ Properties window 79
FIGURE 3-15 FWZ Properties — CA Key tab 53 FIGURE 4-7 ISAKMP Properties windows 80
FIGURE 3-16 FWZ Properties — DH Key tab 54 FIGURE 4-8 Users Manager window 80
FIGURE 3-17 FWZ Properties — Encapsulation FIGURE 4-9 User Properties window - S/Key
tab 55 Authentication 81
FIGURE 3-18 A gateway’s public key 56 FIGURE 4-10 User Encryption Properties windows
(FWZ and ISAKMP) 82
FIGURE 3-19 User Properties window - Encryption
tab 57 FIGURE 4-11 SecuRemote Client User Authentication
and Password windows 84
FIGURE 3-20 ISAKMP Properties windows 58
FIGURE 4-12 Client Encryption Properties window
FIGURE 3-21 FWZ Properties window 60 (OpenLook) and User Encryption Action
Properties window (Windows) 88
FIGURE 3-22 Properties window — General tab 61
FIGURE 4-13 Two FireWalls and Encryption
FIGURE 3-23 ISAKMP Properties window 62
Domains 90
FIGURE 3-24 SKIP Encryption Properties
FIGURE 4-14 SecuRemote user connecting to a host
window 63
inside a site’s encryption domain 95
FIGURE 3-25 Manual IPSec Encryption Properties
FIGURE 4-15 FWZ Encryption Properties —
window (Windows) and the Rule
Encapsulation tab (Windows GUI) 97
Encryption Properties window
(OpenLook) 65 FIGURE 5-1 Network configuration before and after
SecuRemote installation 104
FIGURE 3-26 Authentication Keys window 66
FIGURE 5-2 Existing Version Found window 107
FIGURE 3-27 Manual IPSec window 67
FIGURE 5-3 Choose Destination Location
FIGURE 3-28 FWZ Encryption Properties
window 107
window 69
FIGURE 5-4 Uninstalling SecuRemote 108
FIGURE 3-29 Certificate Authority Key window 70
FIGURE 5-5 Network showing two FW-1
FIGURE 4-1 SecuRemote Example
adapters 109
Configuration 74
FIGURE 5-6 Sites window 111
FIGURE 4-2 Users window 77
FIGURE 5-7 Verify Site reminder (Password and
FIGURE 4-3 User Properties window — General
Certificate) 112
tab 78
FIGURE 5-8 Site window 113
viii Virtual Private Networking with FireWall-1 • September 1998

FIGURE 5-9 Sites window showing newly added
sites 113
FIGURE 5-10 Site List 114
FIGURE 5-11 Site window 115
FIGURE 5-12 SecuRemote Client User Authentication

and Password windows 116
FIGURE 5-13 Password window 118
FIGURE 5-14 SecuRemote Client User Authentication

window 119
FIGURE 5-15 Certificate window (User and CA

tabs) 120
FIGURE 5-16 Options window 120
FIGURE 5-17 Configure Entrust.INI window 122
FIGURE 5-18 Create User window 123
FIGURE 5-19 Recover User window 124
FIGURE 5-20 Properties menu 124
FIGURE 5-21 Configure Single SignOn

window 125
FIGURE 5-22 Single SignOn Enabled window 126
FIGURE 5-23 Disabling Single SignOn

window 126
FIGURE 5-24 SecuRemote Client Toolbar 130
FIGURE 6-1 Network Configuration for

Troubleshooting Examples 133
Figures ix
x Virtual Private Networking with FireWall-1 • September 1998
Tables
TABLE P-1 Typographic Conventions xv TABLE 5-2 Encryption Method

Supported 116
TABLE P-2 Shell Prompts xv
TABLE 5-3 Encryption Method Used 117
TABLE 1-1 Encryption Schemes 7
TABLE 5-4 Properties menu items and their
TABLE 1-2 Comparison of Encryption
corresponding menu
Schemes 11
commands 125
TABLE 2-1 Rule Base without Encryption 22
TABLE 5-5 File Menu Commands 127
TABLE 2-2 Explanation of Rule Base 22
TABLE 5-6 View Menu Commands 127
TABLE 2-3 Rule Base with Encryption Rule
TABLE 5-7 Sites Menu Commands 128
Added 23
TABLE 5-8 Password Menu Commands 128
TABLE 2-4 FWZ Key Hierarchy 24
TABLE 5-9 Tools Menu Commands 128
TABLE 3-1 Client About SecuRemote window
text and encryption methods 59 TABLE 5-10 Entrust Menu Commands 129
TABLE 4-1 How Alice and Bob connect 76 TABLE 5-11 Help Menu Commands 129
TABLE 4-2 Encryption Method TABLE 5-12 Toolbar buttons and their
Supported 84 corresponding menu
commands 130
TABLE 4-3 Encryption Method Used 85
TABLE 6-1 Errors Reported by Alice (Encrypting
TABLE 4-4 Combinations of the Encapsulate
Gateway) 133
SecuRemote connections Field and
the SecuRemote Version 97 TABLE 6-2 Errors Reported by Bob (Decrypting
Gateway) 137
TABLE 4-5 SecuRemote Errors 101
TABLE 6-3 Extended Encryption Protocol —
TABLE 5-1 Minimum Requirements (GUI
Key Update Protocol Errors 140
Client) 105
Tables xi
TABLE 6-4 Fetching Keys from a Remote
Certificate Authority Errors 141
TABLE 6-5 Default path for userc.c 145
xii Virtual Private Networking with FireWall-1 • September 1998

Preface
Scope
The FireWall-1 User Guide describes all CheckPoint FireWall-1 products, and consists
of the following books:
Getting Started with FireWall-1
This book introduces FireWall-1 and describes the FireWall-1 installation process.
Managing FireWall-1 Using the OpenLook GUI
This book describes how to manage FireWall-1 using the OpenLook Graphical User
Interface (GUI).
Managing FireWall-1 Using the Windows GUI
This book describes how to manage FireWall-1 using the Microsoft Windows Graphical
User Interface (GUI).
FireWall-1 Architecture and Administration
This book is the technical reference to FireWall-1 features, including authentication

and address translation. In addition, chapters on troubleshooting and Frequently Asked
Questions (FAQ) are included.
Virtual Private Networking with FireWall-1
This book describes how to establish a Virtual Private Network using FireWall-1.
xiii
Account Management Client
This book describes how to install and use the Check Point Account Management
Client.
Who Should Use this User Guide

This User Guide is written for system administrators who are responsible for
maintaining Virtual Private Networks.
It assumes you have a basic understanding and a working knowledge of:

■ system administration
■ the IP and TCP protocols
■ the Unix or Windows operating system
■ the OpenLook or Windows GUI
Summary of Contents
Chapter 1, “Introduction,” is an introduction to the subject of encryption, and
describes how encryption is implemented in FireWall-1.
Chapter 2, “Configuring FireWall-1 Encryption,” decribes how to configure FireWall-1

encryption and set up a Virtual Private Network that is fully integrated with a
FireWall-1 Security Policy.
Chapter 3, “Encryption Properties,” is a reference to those parts of the FireWall-1

Graphical User Interface (GUI) with which encryption properties are defined.
Chapter 4, “SecuRemote Server,” describes the FireWall-1 SecuRemote Server.
Chapter 5, “SecuRemote Client,” describes the SecuRemote Client.
Chapter 6, “Troubleshooting,” describes common problems and their solutions.
xiv Virtual Private Networking with FireWall-1 • September 1998

What Typographic Changes Mean
The following table describes the typographic changes used in this book.
TABLE P-1 Typographic Conventions
Typeface or
Symbol Meaning Example
AaBbCc123 The names of commands, files, Edit your .login file.

and directories; on-screen Use ls -a to list all files.
computer output machine_name% You have mail.
AaBbCc123 What you type, contrasted with machine_name% su

on-screen computer output Password:
AaBbCc123 Command-line placeholder: To delete a file, type rm filename.
replace with a real name or
value
AaBbCc123 Book titles, new words or Read Chapter 6 in User’s Guide.

terms, or words to be These are called class options.
emphasized You must be root to do this.
Shell Prompts in Command Examples

The following table shows the default system prompt and superuser prompt for the C
shell, Bourne shell, and Korn shell.
TABLE P-2 Shell Prompts
Shell Prompt
C shell prompt machine_name%

C shell superuser prompt machine_name#
Bourne shell and Korn shell $
prompt
Bourne shell and Korn shell #
superuser prompt
Preface xv
xvi Virtual Private Networking with FireWall-1 • September 1998
CHAPTER 1
Introduction
In This Chapter
Encryption Technology page 1

Encryption Schemes page 5
SecuRemote page 11
Encryption Technology
The privacy, authenticity and integrity of communications can be ensured by
encrypting data as it passes through the network. This section describes the technology
employed by FireWall-1’s Encryption feature.
Basic Definitions
Encryption
Encrypting a message modifies (“encrypts”) its text (“plaintext” or “cleartext”) so that
the encrypted text (“ciphertext”) can only be read (“decrypted”) with the aid of some
additional information (“key”) known only to the sender and the intended recipient.
Authentication
Authenticating a message verifies the authenticity of both the sender and the message,
checking for possible tampering and interference with the communication.
1
Encrypting a Message
The simplest way to encrypt a message is by using a secret key, one that both encrypts
and decrypts the message. Ensuring the key’s secrecy is critical, since anyone who
knows the key can decrypt and read the message.
abc !&$
FIGURE 1-1 Encrypting and then decrypting with a secret key restores the original message
Sharing a Secret Key

Secret key encryption is simple and fast, but there are two problems associated with
its use:
■ A secure channel is required by which the correspondents can agree on a key
before their first encrypted communication.
Direct face-to-face negotiation may be impractical or unfeasible, and the

correspondents may have to agree on a key by mail or telephone or some other
relatively insecure means.
■ The number of keys required can quickly become unmanageable, since there
must be a different key for each pair of possible correspondents.
Public Key Distribution System

Public key systems, where each correspondent has a pair of keys, can solve both these
problems.
A key pair is composed of two mathematically related keys: a public key known to
everyone, and a private key known only to its owner.
The Diffie-Hellman public key distribution system can be used to share a secret key
without communicating any secret information, so a secure channel is not required for
the key exchange. Also, under this system, only one key pair needs to be managed for
each correspondent (instead of one key for each pair of correspondents). Once the
correspondents have computed the shared secret key, they can use it to encrypt
communications between them.
2 Virtual Private Networking with FireWall-1 • September 1998

Public Key Distribution System
Diffie-Hellman Scheme
Under the Diffie-Hellman scheme, a secret key is agreed on and exchanged as follows
(FIGURE 1-2), using the private and public parts of Alice’s and Bob’s Diffie-Hellman
keys.
1 Bob gets Alice’s public key and performs a calculation involving his own private
key and Alice’s public key.
2 Alice gets Bob’s public key and performs a calculation involving her own private
key and Bob’s public key.
The results of both calculations are the same, and this result serves as the secret
key. In this way, a secret key can be agreed on without any secret information
being communicated. There is no opportunity for an eavesdropper to determine
the secret key.
Alice Bob
Alice Bob Alice Bob
PRIVATE PUBLIC Only the public parts PUBLIC PRIVATE

of the Diffie-Hellman
keys are exchanged
11. Alice performs 22. Bob performs

a calculation a calculation
with her private with his private
key and Bob's key and Alice's
public key public key
Key Key
Calculation Calculation
Engine Engine
Secret Key
SECRET for
Alice and Bob
SECRET
33. The results

of both
calculations
are the same
FIGURE 1-2 Agreeing on a Secret Key by exchanging the public parts of Diffie-Hellman keys
Chapter 1 Introduction 3
RSA Public Keys

In contrast to a Diffie-Hellman public-private key pair, an RSA public-private key pair
is used for encrypting and decrypting messages. A message encrypted with the public
key can only be decrypted with the private key, and vice versa.
Digital Signatures
Generating a Digital Signature
A digital signature acts as proof of the sender’s identity and the message’s integrity.
Digital signatures can be created using a public key encryption system, such as RSA,
as follows:
1 Suppose Bob wants to send Alice a message. First, he computes a hash of the
message.
A hash is a mathematical computation performed on the text of the message.

Since changing even one bit in the message results in a completely different hash,
and since it computationally unfeasible to compute a message from a given hash,
the hash uniquely identifies the message.
2 Next, Bob encrypts the hash with his own private key.
3 Next, he encrypts the message with Alice’s public key.
4 He then sends Alice both the encrypted hash and the encrypted message.
Verifying a Digital Signature

Upon receiving the message, Alice can confirm that the message was indeed sent
by Bob and that it was not tampered with, as follows:
1 First, she decrypts the message using her private key.
Only Alice can do this, because only she knows her private key.
2 Next, she decrypts the hash using Bob’s public key.
3 Alice calculates the hash of the unencrypted message (this is the same calculation
that Bob performed) and compares it to the hash received from Bob.
If they are the same, then Alice can be sure that:

■ The message can only have been sent by Bob, because Bob is the only
person who knows Bob’s private key and thus the only person who could
have encrypted the hash.
■ The message was not tampered with, because the hash Alice calculated is
the same as the hash Bob calculated.

Certificates
Certificates
If Alice and Bob obtain each other’s public keys over an insecure channel, such as the
Internet, they must be certain that the keys are genuine. Alice cannot simply ask Bob
for his public key, because there is the danger that Mallory might intercept Alice’s
request and send Alice his own key instead. Mallory would then be able to read all of
Alice’s encrypted messages to Bob (and Bob would not be able to read them).
For this reason, there must be a trusted third party, known as a Certificate Authority
(CA), from whom Alice can reliably obtain Bob’s public key, even over an insecure
channel.
The CA sends Alice a certificate, which consists of:

■ Bob’s unique identifier (for example, his LDAP Distinguished Name)
■ Bob’s public key
■ the CA’s digital signature, encrypted with the CA’s private key
Alice can verify the certificate (this is equivalent to verifying Bob’s public key) by the
procedure described in “Verifying a Digital Signature” on page 4. To do this, she needs
the CA’s public key, which must be reliably available from an out-of-band source such
as a printed directory.
Alice does not have to obtain Bob’s certificate directly from the CA. Bob can obtain the
certificate and send it to anyone who requests it, because a certificate cannot be
tampered with.
The certificate is “proof” that the message (in this case, Bob’s public key) is genuine.
Alice and Bob can use each other’s public keys with confidence only if they are
certified by certificates from a trusted CA.
Certificate Authorities
In the FWZ encryption scheme (see “FWZ (FireWall-1) Encryption Scheme” on page 7),
FireWalled Management Servers function as Certificate Authorities for the encrypting
gateways. See “Encryption Setup — FWZ” on page 52 for more information.
In the ISAKMP encryption scheme (see “ISAKMP/OAKLEY Encryption Scheme” on

page 10), the Entrust PKI (Public Key Infrastructure) can be used to obtain certificates
for the encrypting gateways (see “Encryption Setup — ISAKMP/OAKLEY” on page 43)
and for SecuRemote users (see “ISAKMP Properties” on page 58 and “Certificates” on
page 27 of FireWall-1 SecuRemote Client).
Encryption Schemes
Elements of an Encryption Scheme
An encryption scheme consists of the following elements:
1 an encryption algorithm for encrypting messages
Encryption Schemes
2 an authentication algorithm for ensuring integrity, that is, that messages have not
been tampered with
Note – In the context of encryption, authentication means ensuring data integrity.
3 a key management protocol for generating and exchanging keys
Encryption Schemes Supported by FireWall-1

FireWall-1 supports the following encryption schemes:
1 FWZ, a proprietary FireWall-1 encryption scheme
FWZ is described in “FWZ (FireWall-1) Encryption Scheme” on page 7.
2 Manual IPSec
Manual IPSec is an encryption and authentication scheme that uses fixed keys.
Manual IPSec is described in “Manual IPSec Encryption Scheme” on page 8.
3 SKIP (Simple Key-Management for Internet Protocols)
SKIP, developed by Sun Microsystems, adds two features to Manual IPSec:

■ improved keys
Manual IPSec uses fixed keys. In contrast, SKIP uses a hierarchy of

constantly changing keys.
■ key management
Manual IPSec does not provide a mechanism by which users can exchange
keys. SKIP implements a key management protocol for Manual IPSec.
SKIP is described in “SKIP Encryption Scheme” on page 9.
4 ISAKMP/OAKLEY1
Like SKIP, ISAKMP/OAKLEY (commonly known as ISAKMP) adds key

management features to Manual IPSec.
ISAKMP/OAKLEY is described in “ISAKMP/OAKLEY Encryption Scheme” on

page 10.
1.ISAKMP stands for Internet Security Association and Key Management Protocol. OAKLEY is a protocol for
exchanging keys and deriving keying material.

The relationship between the components of the encryption schemes, as implemented

in FireWall-1, is described in TABLE 1-1.
TABLE 1-1 Encryption Schemes
encryption authentication encryption

scheme algorithm algorithm encryption is ...
FWZ MD5 DES, FWZ1 in-place
Manual IPSec MD5, SHA-1, DES, RC2 encapsulated
CBC-DES MAC
SKIP MD5, SHA-1, DES (triple DES for encapsulated
CBC-DES MAC key encryption) —
the traffic
encryption is IPSec
ISAKMP/OAKLEY MD5, SHA-1 DES (triple DES for encapsulated
key encryption),
CAST, RC5 — the
traffic encryption is
IPSec
DES, FWZ1, CAST, RC2, RC4 and RC5 are all encryption algorithms used to encrypt
the data portion of a packet.
FWZ (FireWall-1) Encryption Scheme

Under the FireWall-1 encryption scheme (FWZ), a message is encrypted with a secret
key derived in a secure manner from the correspondents’ Diffie-Hellman keys (see
“Diffie-Hellman Scheme” on page 3). The Diffie-Hellman keys are authenticated by a
Certificate Authority.
TABLE 1-2 on page 11 lists the keys used in the FWZ encryption scheme.
Under this scheme, the number of keys that must be managed is proportional to the
number of correspondents. This is in contrast to some other schemes, in which the
number of keys to be managed is proportional to the square of the number of
correspondents.
The TCP/IP packet headers are not encrypted, to ensure that the protocol software will
correctly handle and deliver the packets. The cleartext TCP/IP header is combined with
the session key (derived from the Basic Session Key; see TABLE 1-2 on page 11 for
details) to encrypt the data portion of each packet, so that no two packets are
encrypted with the same key. A cryptographic checksum is embedded in each packet
(utilizing otherwise unused bits in the header) to ensure its data integrity.
Encryption is in–place. A packet’s length remains unchanged, so the MTU remains

valid and efficiency is not compromised.
Encryption Schemes
Manual IPSec Encryption Scheme

Manual IPSec is an encryption and authentication scheme. A Security Association (SA)
is associated with each packet, consisting of:
■ functionality — indicates whether the packet is encrypted, authenticated, or both
■ algorithms — specifies the encryption algorithm (for example, DES) and the
authentication algorithm (for example, MD5) used in the packet
■ keys used in the above algorithms
■ additional data, for example, initialization vector (IV)
A 32-bit number, known as the Security Parameters Index (SPI), identifies a specific
SA. An SPI is simply an identifier, assigned by the correspondents themselves in a
particular context, and has no meaning outside that context.
Encryption
IP packets are encrypted in accordance with the Encapsulating Security Payload (ESP)
standard (RFC 1825, 1827 and 1829). As its name implies, the ESP standard
specifies that the original packet is encrypted and then encapsulated into a new, longer
packet. There are two modes of performing this encapsulation:
■ Tunnel Mode
■ Transport Mode
Tunnel Mode
In the tunnel mode, the entire packet (including the IP header) is encrypted in
accordance with the SA previously decided upon by the correspondents. An ESP header
containing the SPI and other data is added to the start of the packet, and a new IP
header is constructed.
The new packet (which is of course larger than the original packet) consists of:
■ the new IP header
■ the ESP header
■ the encrypted original packet
The new packet is then sent on its way. An advantage of this mode is that the
destination specified in the new IP header may be different from the one in the
original IP header. It is thus possible to send the packet to a host which performs
decryption on behalf of a number of other hosts; the decrypting host decrypts the
packet, strips the ESP and IP headers added by the encrypting host, and then sends
the original packet to its destination. Tunnel mode closely corresponds to the
FireWall-1 encryption model, where gateways encrypt and decrypt on behalf of other
hosts.

Transport Mode (not supported by FireWall-1)
In the transport mode, the IP header is not encrypted. An ESP header is inserted
between the IP header and the transport layer header. The transport layer header and
everything following is encrypted.
This mode does not increase the length of the packet as much as the Tunnel Mode
does (no additional IP header is added). The encrypted packet must be sent to its
original destination.
Transport mode is not supported by FireWall-1, because it is designed for end-to-end

encryption, and does not allow for the case where gateways encrypt and decrypt on
behalf of other hosts.
Authentication
If authentication is specified by the SA, then an Authentication Header (AH) is added
to the packet, in addition to the ESP header (and to the second IP header in Tunnel
Mode).
FireWall-1 conforms to the Authentication standards described by RFC 1825, 1826,

1828 and 1852.
Shortcomings
Manual IPSec has two shortcomings:
■ the keys are fixed for the connection’s duration
■ there is no mechanism for exchanging keys
Both SKIP and ISAKMP/OAKLEY address these shortcomings.
SKIP Encryption Scheme

SKIP provides a hierarchy of keys that change over time, which are used to encrypt the
connection as well as to implement a key management protocol. SKIP also includes ESP
and AH, and adds its own header to the packet.
The Encryption Key and the Authentication Key are derived from the Session Key,
which changes at fixed intervals, or when the amount of data encrypted exceeds a
given threshold. The newly changed Session Key is communicated by encrypting it
with the Kijn key, which changes once every hour. The Kijn key is derived from the
Diffie-Hellman shared secret Kij key, using a cryptographic hash function (see “Diffie-
Hellman Scheme” on page 3). Each correspondent obtains the public part of the other
correspondent’s Diffie-Hellman key from a Certificate Authority, which signs the
transmission with its own RSA key.
SKIP includes a protocol (Certificate Discovery Protocol) for this exchange of public
keys. However, this protocol is not supported by FireWall-1, which uses instead a
proprietary protocol for key exchange. FireWall-1 also supports manual key exchange.
Encryption Schemes
ISAKMP/OAKLEY Encryption Scheme

ISAKMP/OAKLEY is a standard for negotiating Security Associations (SA) between two
hosts that will be using IPSec, and is the key management scheme that was chosen for
IP Version 6. In IP Version 4, ISAKMP/OAKLEY is optional. ISAKMP/OAKLEY offers
improved authentication (HMAC) and Perfect Forward Secrecy (PFS).
The FireWall-1 implementation of ISAKMP/OAKLEY supports the Entrust PKI (Public

Key Infrastructure).
ISAKMP/OAKLEY key exchange is divided into two phases:
ISAKMP Phase One (Main/Aggressive Mode)

In this phase, the peers negotiate an ISAKMP Security Association that will be used for
encrypting and authenticating Phase Two exchanges. Phase One involves long and
CPU-intensive computations, and so is executed infrequently. A cookie exchange
mechanism precedes the computations in order to prevent denial-of-service attacks.
The negotiated SA includes the encryption method, authentication method and keys.
This SA is used in the Phase Two negotiation.
FireWall-1 supports two modes for Phase One:

■ aggressive mode (the default), in which three packets are exchanged
■ main mode, in which six packets are exchanged
ISAKMP Phase Two (Quick Mode)

Using the SA negotiated in Phase One, the peers negotiate an SA for encrypting the
IPSec traffic. Keys can be modified as often as required during a connection’s lifetime
by performing Phase Two.

Comparison of Encryption Schemes
Comparison of Encryption Schemes

TABLE 1-2 presents a high-level comparison of the encryption schemes supported by
FireWall-1.
TABLE 1-2 Comparison of Encryption Schemes
feature FWZ Manual IPSec SKIP ISAKMP/OAKLEY

portability CheckPoint standard standard industry
proprietary supported by standard
Sun and other
vendors
key management yes no yes yes
Session Keys each TCP or fixed keys change keys change at
UDP session over time or as configurable
has a new key amount of data times during a
encrypted connection’s
exceeds lifetime
threshold
number of keys required number of square of the number of square of the
is proportional to the ... correspondents number of correspondents number of
correspondents correspondents
packet size unchanged increased increased increased
gateway can encrypt/ yes yes (in Tunnel yes (in Tunnel yes (in Tunnel
decrypt on behalf of Mode) Mode) Mode)
other hosts
SecuRemote
Overview
Check Point SecuRemote enables mobile and remote Microsoft Windows 95 and
Windows NT (Intel only) users to connect to their enterprise networks via dial-up
Internet connections —either directly to the server or through Internet Service
Providers — and communicate sensitive corporate data safely and securely. Check
Point SecuRemote extends the Virtual Private Network (VPN) to the desktop and
laptop.
Other uses for SecuRemote are:

■ Specific employees can be granted encrypted access to sensitive corporate data.
■ A server can be set up to provide encrypted information to paying customers
only. Because the communication is encrypted, eavesdropping is impossible.
■ Users at a remote office can conduct encrypted communications with the
FireWalled enterprise network without installing FireWall-1 at the remote office.
SecuRemote
Check Point SecuRemote is based on a technology called Client Encryption. Because

SecuRemote encrypts data before it leaves the laptop, it offers a completely secure
solution for remote connections.
SecuRemote can transparently encrypt any TCP/IP communication. There is no need to

change any of the existing network applications on the user’s PC. SecuRemote can
interface with any existing adapter and TCP/IP stack. A PC on which SecuRemote is
running can be connected to several different sites that use FireWall-1’s VPN.
A FireWall-1 security manager can enable access for SecuRemote users with the
standard FireWall-1 Rule Base editor. After a SecuRemote user is authenticated, a
completely transparent secured connection is established and the user is treated just as
any user in the Virtual Private Network. The network administrator can enforce
FireWall-1 security features, including authentication servers, logging and alerts, on
SecuRemote connections (just as with any other connection).
The configuration below depicts a Virtual Private Network with a nomadic SecuRemote
user securely connected to the Enterprise network through the Internet.
Corporate Headquarters
HP
SecuRemote
Server Sun
IBM
AIX
SecuRemote
SecuRemote Server
Server
South
American Asian
Office Internet Office
SecuRemote NT
Client
SecuRemote
Server
European Office
FIGURE 1-3 Virtual Private Network with a nomadic SecuRemote Client

Additional Information
SecuRemote includes support for dynamic IP addressing, which is necessary for dial-up
communication. SecuRemote can also be used from stationary PC’s with fixed IP
addresses.
SecuRemote supports ISAKMP key exchange, as well as the proprietary FWZ protocol.
Strong user authentication is supported by means of Entrust certificates, as well as a
number of other authentication schemes (RADIUS, S/Key, password etc). Encryption
schemes include (in accordance with export restrictions):
■ IPSec using DES, triple DES or 40 bit encryption
■ FWZ (a Check Point proprietary scheme) using DES or FWZ1
Additional Information
For information about configuring the SecuRemote Server (FireWall Module), see
Chapter 4, “SecuRemote Server.”
For information about the SecuRemote Client software, see Chapter 5, “SecuRemote
Client.”
SecuRemote

CHAPTER 2
Configuring
FireWall-1 Encryption
In This Chapter
FireWall-1 Encryption — Overview page 15

Configuration Examples page 17
FWZ Encryption Protocol — Detailed Description page 32
FireWall-1 Encryption — Overview

FireWall-1 provides completely transparent selective encryption for a wide range of
services. Encryption, decryption, and key management are all seamlessly integrated
with other FireWall-1 features.
FIGURE 2-1 depicts a corporate internetwork where two private networks are connected
via the Internet through FireWalled gateways. HQ is the Management Station for itself
and London. The private networks (HQ-net, London-net and DMZ-net) are protected
by the FireWalled gateways, but the public part of the network — the Internet — must
be considered insecure.
Note – A Management Station is a workstation on which the FireWall-1 Security Policy

is defined and maintained. Other FireWall-1 components are Masters, which receive
logs and alerts, and FireWalled hosts (usually gateways), which enforce the Security
Policy.
15
FireWall-1 Encryption — Overview
PRIVATE PUBLIC PRIVATE
HQ-net London-net
Internet
Admin HQ London Support

(FireWalled (FireWalled
gateway) gateway)
encrypted
RandD Sales
mailsrvr
not encrypted
ftp DMZ-net
http
FIGURE 2-1 Two Gateway Network Configuration
Encryption Domains
A gateway performs encryption on behalf of its encryption domain: the local area
network (LAN) or group of networks that the gateway protects. Behind the gateway, in
the internal networks, packets are not encrypted.
For example, if the system administrator has specified that communications between
HQ and London are to be encrypted, FireWall-1 encrypts packets traveling between
them on the Internet. A packet traveling from Sales to Admin is encrypted on the
London-HQ segment of its trip, but not encrypted on the Sales-London and HQ-Admin
segments.
In this way, encryption can be implemented for a heterogeneous network without the
need to install and configure encryption on every host in the network.
Key Management
Key management is based on the Diffie-Hellman and RSA schemes described above
(see “Diffie-Hellman Scheme” on page 3). For each gateway it manages, a Management
Station:
■ generates the gateway’s Diffie-Hellman key pair
■ distributes the key pair to the gateways in a secure manner
■ acts as the gateway’s Certificate Authority
Note – FireWall-1 manages this information using secure protocols that ensure its
authenticity and prevent “man in the middle” attacks.

Specifying Encryption
At the start of an encrypted session, the gateways compute a secret key from their
Diffie-Hellman keys and then begin encrypted communications.
Configuration Examples
In This Section
Specifying Encryption page 17

A Two Gateway Configuration (FWZ) page 17
A Two Gateway Configuration (Manual IPSec) page 24
A Two Gateway Configuration (SKIP) page 25
A Two Gateway Configuration (ISAKMP/OAKLEY) page 26
A Three Gateway Configuration page 29
Encrypting Communications with External Networks page 30
When Keys Change page 32
Internal Encryption page 32
Specifying Encryption
To specify encryption, you must answer the following questions:
1 Who will encrypt?
Define the encrypting gateways and their encryption domains.
2 What are the encryption keys?
On the Management Station, generate keys for the gateways, or obtain the
certified keys from the remote gateways or Certificate Authorities.
3 What will be encrypted?
Add a rule (or rules) specifying encryption to the Rule Base.
4 Which encryption scheme will be used?
Specify the encryption scheme in the rule. The scheme must be one that both
parties to the encryption can implement.
A Two Gateway Configuration (FWZ)

To encrypt communications between HQ’s encryption domain and London’s encryption
domain (FIGURE 2-1 on page 16) using the FWZ encryption scheme, proceed as follows
on HQ, their Management Station:
1 Define the gateways that will perform the encryption.
If you are adding encryption to an existing FireWall-1 configuration, the gateways

are already defined. Otherwise, define HQ and London as gateways.
Chapter 2 Configuring FireWall-1 Encryption 17

2 Define HQ-net, DMZ-net, and London-net as networks..
FIGURE 2-2 Workstation Properties for an encrypting gateway (OpenLook and Windows)
3 To define a gateway’s encryption keys, open the Workstation Properties window

(FIGURE 2-2 on page 18) for each encrypting gateway and then:
■ OpenLook GUI — Click on Key Setup.
This displays the Encryption Setup window (FIGURE 2-3 on page 19).
■ Windows GUI — In the Encryption tab, double-click on FWZ Encryption
Method.
This displays the FWZ Properties window (FIGURE 2-4 on page 20).
Note – Make sure that the IP Address field specifies the gateway’s external interface.
4 If the Certificate Authority is local, click on Generate to generate a Diffie-

Hellman key pair for the gateway.

5 If the Certificate Authority is remote, click on Get to retrieve a Diffie-Hellman

key pair for the gateway.
FIGURE 2-3 Encryption Setup window — before a key has been generated
The Diffie-Hellman key is a public-private key pair, and is used to generate the
Basic Session Key (see TABLE 2-4 on page 24).
In this example configuration, all the gateways are controlled from the same
Management Station. For information on external gateways, see “Encrypting
Communications with External Networks” on page 30.

FIGURE 2-4 FWZ Properties window — after a key has been generated
6 In the OpenLook GUI, you can view the public key by clicking on View.
FIGURE 2-5 A gateway’s public key (OpenLook)
In the Windows GUI, the public key is displayed in the DH Key tab of the
Properties window (FIGURE 2-4 on page 20).
7 In the Workstation Properties window for each gateway, specify the Encryption
Domain.
In the example configuration, HQ’s Encryption Domain is HQ-encrypted (a group

consisting of HQ-net and DMZ-net), and London’s Encryption Domain is London-
net.
8 Define a network object group (for example, “Enterprise”) consisting of all the
networks that will participate in the encryption (HQ-net, DMZ-net, and
London-net).

9 Define a rule in the Rule Base that specifies Encrypt as the Action for
communications whose source and destination are the network object group
defined in the previous step.
Source Destination Services Action Track Install On
Enterprise Enterprise Any Encrypt Long Log Gateways
The Encrypt action means

■ encrypt outgoing packets
■ accept incoming encrypted packets and decrypt them
10 Double-click on Encrypt and specify the rule’s encryption properties in the

Encryption Properties window.
FIGURE 2-6 Encryption Properties window
Session Key Encryption Method specifies the encryption algorithm for session
keys. Choose FWZ1 or DES (where available).
Data Encryption Method specifies the encryption algorithm for communications

packets. Choose FWZ1 or DES (where available).
Data Integrity Method specifies the cryptographic checksum method to be used

for ensuring data integrity.
Peer Gateways should be set to Any, meaning that each gateway is prepared to
conduct encrypted sessions with all the other gateways, in accordance with their
encryption domains.
Diagnostics Track specifies the action to be taken if protocol errors are detected.

11 Install the Security Policy on the gateways (HQ and London).

Adding an Encryption Rule to a Rule Base
TABLE 2-1 shows a typical Rule Base for the network configuration shown in FIGURE 2-1
on page 16. “OurGWs” is a group that includes HQ and London.
TABLE 2-1 Rule Base without Encryption
1 Any OurGWs Any Reject Long Log Gateways

2 DMZ-net Enterprise Any Reject Long Log Gateways
3 Enterprise Any Any Accept Short Log Gateways
4 Any DMZ ftp, http, smtp Accept Short Log Gateways
5 AllUsers@Any Any telnet UserAuth Long Log Gateways
6 Any Any Any Reject Long Log Gateways
The Rule Base is explained in TABLE 2-2.
TABLE 2-2 Explanation of Rule Base
Rule No. Explanation

1 prevents all users from getting on the gateways
2 prevents DMZ-net from initiating traffic to the internal networks
3 allows all internal hosts to go out to the Internet
4 allows unrestricted access to HTTP, FTP and MAIL services on DMZ
5 specifies User Authentication for incoming telnet to internal hosts
6 rejects and logs all other communications
The encryption rule should be inserted before the third rule in the Rule Base. In this
way, mail between Enterprise hosts will be encrypted, but mail from an Enterprise host
to other hosts will not be encrypted.
TABLE 2-3 on page 23 shows the Rule Base after the encryption rule has been added
before the original third rule, which has now become the fourth rule.

TABLE 2-3 Rule Base with Encryption Rule Added
1 Any OurGWs Any Reject Long Log Gateways

2 DMZ-net Enterprise Any Reject Long Log Gateways
3 Enterprise Enterprise Any Encrypt Long Log Gateways
4 Enterprise Any Any Accept Short Log Gateways
5 Any DMZ ftp, http, smtp Accept Short Log Gateways
6 AllUsers@Any Any telnet UserAuth Long Log Gateways
7 Any Any Any Reject Long Log Gateways
Virtual Encryption Session (FWZ)

Following is a detailed description of what actually happens when FireWall-1 applies
the encryption rule in the Rule Base described above using the FWZ encryption
scheme.
Suppose Admin (one of the hosts in HQ’s encryption domain) initiates an SMTP
session with Support (one of the hosts in London’s encryption domain).
■ When the first SMTP packet reaches HQ, HQ inspects its Rule Base and
determines that the session must be encrypted, and that the source address
(Admin) is in its own encryption domain.
■ HQ searches the FireWall-1 network objects database and finds that the
destination address (Support) is in London’s encryption domain.
■ HQ notifies London that an encrypted session is to take place between them.
■ HQ and London compute a secret Basic Session Key (BSK) using the scheme
described above (see “Diffie-Hellman Scheme” on page 3).
■ HQ and London conduct a secured key exchange protocol during which they
agree on a randomly generated session key (a DES or FWZ1 key, depending on
the relevant rule’s properties) for the encrypted SMTP session, which then
begins.
The TCP/IP packet headers are not encrypted, to ensure that the protocol software will
correctly handle and deliver the packets. The cleartext TCP/IP header is combined with
the session key to encrypt the data portion of each packet, so that no two packets are
encrypted with the same key. A cryptographic checksum is embedded in each packet
(utilizing otherwise unused bits in the header) to ensure its data integrity.
Encryption is in–place. A packet’s length remains unchanged, so the MTU remains

valid and efficiency is not compromised. Key management and encryption are secure,
completely integrated, and transparent to the user.

FWZ Key Hierarchy

TABLE 2-4 shows the hierarchy of FWZ encryption keys. The system administrator
configures the first two keys (Certificate Authority and Encryption). The other keys are
automatically generated by FireWall-1 for each Virtual Encryption Session.
The Basic Session Key is derived from the Diffie-Hellman key when the Virtual
Encryption Session begins, using the mechanism depicted in FIGURE 1-2 on page 3. The
Session Key is randomly generated and encrypted using the Basic Session Key in
accordance with the encryption method — DES or FWZ1 — specified for the rule. The
Packet Key is derived by combining the Session Key with some bytes of the TCP/IP
header, so that no two packets are encrypted with the same key.
TABLE 2-4 FWZ Key Hierarchy
associated
key managed by type with comments
Certificate CA RSA public key Management used to authenticate
Authority (CA) (512 bits) Station or the communication
key external CA of a gateway’s
public encryption
key
Encryption key user Diffie-Hellman gateway used to generate the
public key (512 bits) Basic Session Key
Basic Session automatically shared Diffie- gateway pair used to encrypt the
Key (BSK) generated when Hellman secret key Session Key
the session begins (512 bits)
Session Key (SK) automatically depends on the session randomly generated,
generated encryption algorithm encrypted using the
BSK
Packet Key automatically depends on the packet combination of the
generated encryption algorithm Session Key and IP
header
A Two Gateway Configuration (Manual IPSec)

Under Manual IPSec, gateways do not have encryption properties. Instead, encryption
properties are defined individually for each rule.

domain (FIGURE 2-1 on page 16) using Manual IPSec when both HQ and London are
FireWalled, proceed as follows:
1 Define two SPIs (for example, 0x102 and 0x103) on both HQ and London.
Make sure the two SPIs have the same meanings on both HQ and London. Note
that it’s also possible to use a single SPI.

A Two Gateway Configuration (SKIP)
■ In the Windows GUI, SPIs are defined in the SPI tab of the Manual IPSec
window (FIGURE 3-27 on page 67). For more information, see “Defining an
SPI (Windows)” on page 66.
■ In the OpenLook GUI, SPIs are defined in the Rule Encryption Properties
window for a Manual IPSec rule (FIGURE 3-25 on page 65). For more
information, see “Manual IPSec Encryption Properties” on page 65.
2 Select Manual IPSec in the Encryption Setup window.
3 On HQ, define a rule with Manual IPSec encryption for communications from
HQ to London.
4 In the Encryption Properties window for the rule, specify the SPI as 0x102 and
the Peer Gateway as London.
5 On London, define a rule with Manual IPSec encryption for communications

from London to HQ.
6 In the Encryption Properties window for the rule, specify the SPI as 0x103 and
the Peer Gateway as HQ.
The rest of the procedure is the same as described in “A Two Gateway Configuration
(FWZ)” on page 17.
If only one of the gateways is FireWalled and the other is not, you will not be able to
define the SPI using FireWall-1 on the other gateway. Instead, you will have to use
whatever tools are available on that gateway for defining SPIs.
For additional information, see “Manual IPSec Encryption Properties” on page 65,
“Defining an SPI (OpenLook)” on page 66 and “Defining an SPI (Windows)” on
page 66.
A Two Gateway Configuration (SKIP)

domain (FIGURE 2-1 on page 16) using SKIP when both HQ and London are FireWalled,
proceed according to the instructions under “A Two Gateway Configuration (FWZ)” on
page 17. The only difference is that in this case, you would choose SKIP under Scheme
in the Encryption Setup window (FIGURE 3-10 on page 47) and in the rule’s Encryption
Properties window (FIGURE 2-6 on page 21).
Note – Make sure that the IP Address field in the Workstation Properties window (see
FIGURE 2-2 on page 18) specifies the gateway’s external interface. If you fail to do so,
SKIP encryption will not function properly.
If only one of the gateways is FireWalled and the other is not (for example, if HQ is
FireWalled and London is not), you will not be able to automatically fetch the non-
FireWalled gateway’s key to the FireWalled gateway. Instead, proceed as follows on the
FireWalled gateway (HQ):

1 Put London’s key in a binary file using the Write button in the SKIP Encryption
Setup window (FIGURE 3-10 on page 47) or SKIP Properties window (FIGURE 3-12
on page 50).
Warning – If you fetch London’s key over the Internet (for example, using FTP), then
you should verify the key by some other non-network means, such as by fax or
telephone.
2 Define London as an external gateway (in the General tab of the Workstation
Properties window) on which FireWall-1 is not installed.
3 Open London’s Encryption Setup window.
4 Choose SKIP under Scheme.
5 Choose None under Certificate Authority.
The Generate button changes to Read.
6 Select Read and enter the name of the file in which you saved London’s key.
The rest of the procedure is the same as described in “A Two Gateway Configuration
(FWZ)” on page 17.
A Two Gateway Configuration (ISAKMP/OAKLEY)

Both Gateways FireWalled
domain (FIGURE 2-1 on page 16) using the ISAKMP encryption scheme, proceed as
follows on HQ, their Management Station:
1 Define the gateways that will perform the encryption.
If you are adding encryption to an existing FireWall-1 configuration, the gateways

are already defined. Otherwise, define HQ and London as gateways.
For each gateway, make sure that the IP Address field specifies the gateway’s
external interface.
2 Define HQ-net, DMZ-net, and London-net as networks.
3 To define a gateway’s encryption keys, open the Workstation Properties window

(FIGURE 2-2 on page 18) for each encrypting gateway and then:
■ OpenLook GUI — Click on Encryption Setup.
This displays the Encryption Setup window (FIGURE 2-3 on page 19).
■ Windows GUI — In the Encryption tab, check ISAKMP/OAKLEY Encryption
Method and then double-click on it.

A Two Gateway Configuration (ISAKMP/OAKLEY)
This displays the ISAKMP Properties window (FIGURE 2-7).
FIGURE 2-7 ISAKMP Properties window and Encryption Setup (ISAKMP) window
4 In the Workstation Properties window for each gateway, specify the Encryption
Domain.
In the example configuration, HQ’s Encryption Domain is HQ-encrypted (a group

consisting of HQ-net and DMZ-net), and London’s Encryption Domain is London-
net.
5 Define a network object group (for example, “Enterprise”) consisting of all the
networks that will participate in the encryption (HQ-net, DMZ-net, and
London-net).
6 Define a rule in the Rule Base that specifies Encrypt as the Action for
communications whose source and destination are the network object group
defined in the previous step.
Enterprise Enterprise Any Encrypt Long Log Gateways
The Encrypt action means

■ encrypt outgoing packets
■ accept incoming encrypted packets and decrypt them

7 Double-click on Encrypt and specify the rule’s encryption properties in the

Encryption Properties window, choosing ISAKMP/OAKLEY as the Encryption
Scheme.
FIGURE 2-8 ISAKMP Properties window
In the Windows GUI, this is a two step process:
a Select ISAKMP/OAKLEY in the Encryption Properties window (FIGURE 3-22 on

page 61).
b Click on Edit to display the ISAKMP Properties window (FIGURE 2-8).
For information about the fields in this window, see “ISAKMP/OAKLEY

Encryption Properties” on page 62.
8 Install the Security Policy on the gateways (HQ and London).
Note – Make sure that the IP Address field in the Workstation Properties window (see
FIGURE 2-2 on page 18) specifies the gateway’s external interface. If you fail to do so,
ISAKMP/OAKLEY encryption will not function properly.
Only One Gateway FireWalled

If only one of the gateways is FireWalled and the other is not (for example, if HQ is
FireWalled and London is not), proceed as follows:
1 Define the other gateway (London) as an external object (in the General tab of
the Workstation Properties window).
2 In the ISAKMP Properties window (FIGURE 3-4 on page 43), define the key
exchange parameters.

A Three Gateway Configuration
A Three Gateway Configuration

FIGURE 2-9 on page 29 depicts the network configuration shown in FIGURE 2-1 on
page 16 after a third gateway (Paris) has been added.
To include Paris and its hosts (Louvre and Eiffel) in the encryption, proceed as follows:
1 Define Paris as a gateway.
2 Define Paris-net as a network.
PRIVATE PUBLIC PRIVATE
HQ-net London-net
Internet

gateway) gateway)
RandD Sales
mailsrvr DMZ-net
ftp
http
PRIVATE
Paris
(FireWalled
gateway)
encrypted
Paris-net
not encrypted
Louvre Eiffel
FIGURE 2-9 Three Gateway Network Configuration
3 Add Paris to the OurGWs group.
4 In Paris’ Workstation Properties window, specify its Encryption Domain.
Paris’ Encryption Domain is Paris-net.
5 Add Paris-net to the Enterprise group.
6 In Paris’ Workstation Properties window, click on Key Setup to display the

Encryption Setup window.
7 Click on Generate to generate a key for Paris.
8 Install the Security Policy on the gateways (HQ, London and Paris).

No changes to the Rule Base are necessary, because there is no change in what is being
encrypted.
Encrypting Communications with External Networks

The examples described above assume the encrypting gateways are controlled from the
same Management Station. Encryption can also be implemented between gateways that
are controlled from different Management Stations.
FIGURE 2-10 on page 31 depicts a configuration similar to the one shown in FIGURE 2-9
on page 29, but with an external gateway (Reseller) added. Reseller-net’s HTTP server
is Chile, and its Management Station is Brazil, while the other gateways (HQ, London
and Paris) are all managed by HQ.
Configuring the “Local” Network

In order to encrypt HTTP between Enterprise and Reseller, Enterprise’s system
administrator must proceed as follows on HQ:
1 Define Brazil as an external host (choose External in the Location field in the
Workstation Properties window).
2 Define Reseller-net as a network.
3 Define Reseller as an external gateway.
4 In Reseller’s Workstation Properties window, click on Key Setup to display the

Encryption Setup window.
5 Select Brazil from the Certificate Authority menu.
This specifies that Brazil manages and authenticates Reseller’s keys.
6 Click on Get to obtain Reseller’s public key from Brazil.
Warning – The first time you contact Brazil, its CA public key will be automatically
fetched. However, since this transaction cannot be authenticated, you will get a
warning message. It is advisable that you verify the key just obtained over the
network by some other non-network means, such as by fax or telephone.

Encrypting Communications with External Networks
Chile Peru Brazil
Reseller-net
Reseller
(FireWalled
gateway)
PRIVATE
PRIVATE PRIVATE
PUBLIC
HQ-net London-net
Internet

gateway) gateway)
RandD Sales
mailsrvr DMZ-net
ftp
http
PRIVATE
Paris
(FireWalled
gateway)
encrypted
Paris-net
not encrypted
Louvre Eiffel
FIGURE 2-10 Network Configuration with External Encrypting Gateway
7 In Reseller’s Workstation Properties window, specify its Encryption Domain.
Reseller’s Encryption Domain is Reseller-net.

FWZ Encryption Protocol — Detailed Description
8 In the Rule Base, define a rule for encrypting HTTP.
Enterprise Reseller-net http Encrypt Short Log Gateways
The rule should be placed before any rules accepting HTTP in the Rule Base (see
TABLE 2-3 on page 23).
9 In the new rule, double-click on Encrypt and specify the rule’s encryption
properties in the Encryption Properties window.
10 Install the Security Policy on the gateways.

Configuring the “Remote” Network
Reseller’s system administrator, working on Brazil, must configure Reseller’s Security
Policy as well, performing the same tasks as Enterprise’s system administrator.
When Keys Change

If a gateway’s public Diffie-Hellman key changes, the FireWall-1 daemon on the peer
gateway become aware of the new key when the Security Policy is reinstalled. When an
external gateway’s key changes, FireWall-1 automatically re-fetches the changed key
before computing the session key. FireWall-1 conducts this communication using secure
protocols that ensure its authenticity and prevent “man in the middle” attacks.
Internal Encryption
The examples described above assume that the internal networks can be regarded as
secure. This assumption may not always be appropriate. Even within a single
organization, some communications may demand a higher level of security than others.
FireWall-1 easily accommodates this requirement. For example, encryption can be

implemented for FTP sessions between specific hosts, even if the hosts (which must
have a FireWall-1 FireWall Module installed on them) are all on the same sub-network
protected by the same FireWalled gateway.

Introduction
In the examples that follow, the gateways are named Alice and Bob.
After an encryption connection has been established, both gateways encrypt outgoing
packets and decrypt incoming packets, so the distinction between the encrypting
gateway (Alice) and the decrypting gateway (Bob) is relevant to the direction of the
first packet only. It may be more accurate to speak of the “initiating” and “receiving”
gateways, but for the sake of simplicity the terms “encrypting” and “decrypting” will
be used throughout this discussion.

Basic Encryption (Session Key Exchange) Protocol
The encryption protocol takes place between two peer gateways whenever a new
connection that the Rule Base indicates must be encrypted is established. The
encryption protocol itself consists of the usual two packets: a request for encryption
sent by Alice and the reply returned by Bob. However, if either of the gateways has an
out-of-date version of the other gateway’s key, then an automatic update protocol may
take place as part of the encryption protocol. In this case, the encryption protocol
would include as many as four (4) packets in all.
Basic Encryption (Session Key Exchange) Protocol

▼ Actions Performed by Alice
1 The protocol is initiated by Alice when FireWall-1 receives the first packet of a
connection that the Rule Base indicates must be encrypted. Alice holds this
packet and initiates the encryption protocol for the connection.
2 The protocol software on Alice examines the source and destination addresses to
see if they are in its encryption domain.
The usual case is that the source address is in Alice’s encryption domain but the
destination address is not.
3 Alice then searches the FireWall-1 network objects database for a gateway which
has the destination address in its encryption domain.
In this example, Alice finds that Bob is that gateway.
4 Alice then retrieves Bob’s public key from the database and sends Bob a normal
encryption request RDP1 packet.
The RDP request packet contains:

■ a suggestion for Alice’s public key
■ possible suggestions for Bob’s public key
■ suggestions for the session key encryption method
■ suggestions for the data encryption method
5 The RDP request packet is sent to the original destination address, on the
assumption that Bob is along the route to that address and will intercept the
packet.
The RDP request packet is not sent directly to Bob because there may be more
than one gateway with the destination in its encryption domain.
▼ Actions Performed by Bob

1 FireWall-1 on Bob intercepts the RDP request packet sent by Alice, which
contains the parameters of the original connection packet.
1.RDP (Reliable Data Protocol) is an internal FireWall-1 protocol.

Bob examines the destination address to check whether it is in Bob’s encryption

domain. If it is not in Bob’s encryption domain, then Bob simply ignores the
packet and passes it on.
2 Bob checks its Rule Base to see whether the connection must be encrypted.
3 Bob examines the source address to see if it is in Alice’s encryption domain.
4 Bob compares Alice’s key suggestion for itself to Bob’s version of Alice’s key, and
Alice’s key suggestion for Bob to Bob’s version of its own key.
If they match, then Bob generates a random session key and encrypts it using the
common Basic Session Key obtained from the Diffie-Hellman computation (see
“Diffie-Hellman Scheme” on page 3), or from a cache, if it was computed
previously.
5 Bob sends the session key to Alice in Bob’s RDP reply.
This step ends the RDP protocol, from Bob’s point of view.
▼ Actions Performed by Alice on Receipt of Bob’s Reply

1 FireWall-1 on Alice receives and verifies Bob’s reply.
The verification consists of decrypting and checking the session key.
2 If the verification is successful, then Alice installs the session key for the
connection.
3 Alice encrypts the original first packet and sends it to its destination.
Extended Encryption Protocol (Automatic Key Update)

In the extended protocol, one gateway (Alice or Bob, or even both) may discover that
it does not have a key for the peer, or that the key is out-of-date. In this event, the
gateway will try to obtain a new key from the peer, provided that it has a key for the
peer’s Certificate Authority.
For example, suppose that Alice discovers — while preparing the RDP packet — that it
does not have a key for Bob. If Alice has the public key of Bob’s CA, Alice will ask Bob
for its (possibly new) key, signed by Bob’s CA.
Since all FireWall-1 gateways have (or can obtain) this signature, Bob can supply his
signed key to Alice. Alice then verifies the signature and installs Bob’s key.

CHAPTER 3
Encryption Properties
In This Chapter
Encryption Properties page 35

Properties Setup - Encryption page 36
Workstation Encryption Properties page 39
User Encryption Properties page 56
Rule Encryption Properties page 61
Certificate Authority (FWZ Encryption) page 70
Encrypting Services That Open Back Connections page 71
Encryption properties (the encryption and data integrity methods to be used when
encrypting a connection) are defined for:
1 workstations
A workstation’s encryption properties include all the encryption schemes the

workstation can use when encrypting connections to and from its encryption
domain.
2 users
A user’s encryption properties include all the encryption schemes the user can
use for SecuRemote connections (Client Encryption).
35
Properties Setup - Encryption
3 rules
A rule’s encryption properties specify the specific encryption scheme that the
rule implements. For example, a gateway might be defined as able to use both
FWZ and SKIP. The scheme used for a connection is specified by the rule that
applies to the connection.
In addition, some system-wide encryption properties are defined in the Encryption tab
of Properties Setup window (Windows) and in the Control Properties/Encryption
window (OpenLook). ISAKMP logging options are defined in the Logging and Alerting
tab of the Properties Setup window (Windows) and in the Control Properties/Logging
and Alerting window (OpenLook).
In This Section
Properties Setup - Encryption page 36

Properties Setup - Logging and Alerting page 38
Workstation Encryption Properties page 39
User Encryption Properties page 56
Rule Encryption Properties page 61
Properties Setup - Encryption

This window (FIGURE 3-1 on page 37) defines system-wide encryption properties.
SecuRemote
Respond to unauthenticated cleartext topology requests — If checked, the FireWall
Module will respond to topology requests from SecuRemote Clients even if the request
is not encrypted.
This feature enables backwards-compatibility with earlier versions of the

SecuRemote Client.

Manual IPSec
FIGURE 3-1 Properties Setup — Encryption tab
Manual IPSec
SPI Allocation Range — Enter From and To.
The range is reserved for allocations of Manual IPSec SPIs, and ISAKMP will
allocate SPIs from outside this range.
SKIP
Enable Exportable SKIP — If checked, then FireWall Modules will generate keys for
exportable SKIP (in addition to non-exportable SKIP keys) and conduct SKIP encryption
with other hosts that are enabled only for exportable SKIP.
Chapter 3 Encryption Properties 37

Properties Setup - Logging and Alerting
Change SKIP key every ... seconds (0 for infinity) — the number of seconds after which
the SKIP session key expires
Change SKIP key every ... bytes (0 for infinity) — the number of bytes transferred after
which the SKIP session key expires
ISAKMP Key Renegotiation

Renegotiate IPSec SAs every ... seconds — the number of seconds after which the IPSec
session key expires
Renegotiate ISAKMP SAs every ... minutes — the number of minutes after which the
ISAKMP SA expires
When an IPSec session key or ISAKMP SA expires in the course of an encryption

session, FireWall-1 renogiates the key or SA with the peer and continues the
encryption session with the new key or SA. This process is transparent to the user.
Properties Setup - Logging and Alerting

This window (FIGURE 3-2) defines system-wide logging properties.
FIGURE 3-2 Properties Setup — Logging and Alerting tab
Log ISAKMP Negotiations — This option controls logging ISAKMP negotiation events.

ISAKMP Key Renegotiation
If enabled, the following events are logged:
1 start of ISAKMP daemon
2 beginning and end of Phase One ISAKMP negotiation
3 beginning of ISAKMP Phase Two negotiation
4 sending and receiving ISAKMP notification (error) messages
The Info field in the log contains information about the error.
5 sending and receiving ISAKMP SA delete messages
In Phase Two, the SA’s SPI appears in the text.
6 ISAKMP negotiation errors
Log encryption kernel events — This option controls logging encryption kernel events.
These events are usually errors, for example, scheme or method mismatch,
checksum errors, clock synchronization mismatch, or rekey policy mismatch
(SKIP).
Workstation Encryption Properties

In order for a gateway to perform encryption, you must first define a key and
encryption domain for the gateway. An encryption domain is the set of network objects
on whose behalf the gateway conducts encrypted sessions.
These parameters are specified in the Workstation Properties window (FIGURE 3-3 on
page 40).

FIGURE 3-3 Workstation Properties window (OpenLook) and Encryption tab of Workstation
Properties window (Windows)
The fields in the Workstation Properties window that are relevant to encryption are
explained below:
OpenLook GUI
Encryption Domain — a network object (usually a network or domain) for which this
gateway performs encryption
If all the gateway’s interfaces have been defined in the Network Interfaces
section of the gateway’s Workstation Properties window, then Interfaces can be
selected in Encryption Domain. In this case, the encryption domain is defined as
the union of all the network objects defined in those Valid Addresses fields not
specified as Any, Others, or Open.
Key Info — displays information about the encryption schemes supported by this
workstation

Windows GUI
Encryption Setup — displays the Encryption Setup window (see FIGURE 3-14 on
page 52)
Type — if not Gateway, then Encryption Domain is ignored.
Windows GUI
Encryption Domain — a network object (usually a network or domain) for which this
gateway performs encryption
If all the gateway’s interfaces have been defined in the Interfaces tab of the
gateway’s Workstation Properties window, then Valid Addresses can be selected
in Encryption Domain. In this case, the encryption domain is defined as the
union of all the network objects defined in those Valid Addresses fields not
specified as Any, Others, or Open.
Encryption Methods Defined — Check those encryption methods (schemes) defined for
this machine.
In This Section
Encryption Setup — ISAKMP/OAKLEY page 43

Encryption Setup — SKIP page 47
Encryption Setup — Manual IPSec page 51
Encryption Setup — FWZ page 52
Encryption Setup
The Encryption Setup window (FIGURE 3-14 on page 52) specifies the parameters of a
gateway’s key and enables you to generate a key or fetch one from a Certificate
Authority.
There are is a different Encryption Setup windows for each of the supported encryption
schemes.
Note – The information shown in the Encryption Setup window in the OpenLook GUI
is accessible through the Encryption tab of the Workstation Properties window in the
Windows GUI.
In the OpenLook GUI, an object’s Encryption Setup window is divided into two parts:
■ The upper part displays the object’s name and the encryption schemes it
supports.
■ The lower part displays information about the selected encryption scheme.
To display the Encryption Setup window for a specific encryption scheme, proceed as
follows:

OpenLook
1 Display the Encryption Setup window by pressing Key Setup in the Workstation
Properties window.
2 Make sure the scheme is checked under Supported Schemes.
3 Select the encryption scheme from the Scheme menu.
The lower part of the Encryption Setup window will change to reflect the scheme
you selected.
Windows
In the Encryption tab of the Workstation Properties window, proceed as follows:
1 Make sure the scheme is checked under Encryption Methods Defined.
2 Select the scheme (highlight it).
3 Click on Edit.
The appropriate Encryption Setup window will be displayed.

Encryption Setup
Encryption Setup — ISAKMP/OAKLEY

The parameters defined in the ISAKMP Properties window (Windows) and Encryption
Setup window (OpenLook) relate to the ISAKMP key negotiations and not to encrypted
sessions, whose parameters are defined in the Rule Encryption Properties windows (see
“Rule Encryption Properties” on page 61).
FIGURE 3-4 ISAKMP Properties window and Encryption Setup (ISAKMP) window
Encryption Method — Select at least one of the methods.
Hash Method — Select at least one of the methods.
Authentication Method — Select at least one of the methods:

■ Pre-Shared Secrets — This workstation can authenticate itself by a pre-
shared secret.
If you check Pre-Shared Secrets, then click on Edit Secrets to display the
Shared Secrets window (FIGURE 3-5 on page 44) in which you can define or
modify the pre-shared secret.
■ Public Key Signatures — This workstation can authenticate itself by a
public key signature.
If you check Public Key Signatures, then click on Configure to display the
Public Key Configuration window (FIGURE 3-8 on page 45) in which you can
generate a public key for the workstation and define the matching criteria.

Supports Aggressive Mode — If checked, the standard six packet ISAKMP Phase 1
exchange is replaced by a three packet exchange.
Shared Secrets
FIGURE 3-5 ISAKMP Shared Secrets window
In this window, you define the shared secret between this workstation and other
workstations. The workstations listed are those for which ISAKMP encryption method
is enabled, except for this workstation (that is, the workstation whose properties you
are defining now).
To define a pre-shared secret between this workstation and one of those in the list,
proceed as follows:
1 Select that workstation.
2 Click on Edit (Windows) or Add/Modify ... (OpenLook).
In the Windows GUI, a text box is displayed below the list in which to enter the
pre-shared secret. In the OpenLook GUI, another window is opened for this
purpose.
FIGURE 3-6 Entering a Pre-Shared Secret

Encryption Setup
3 Enter the pre-shared secret and click on Set.
The Shared Secrets window now shows the pre-shared secret next to the
workstation’s name.
FIGURE 3-7 Shared Secrets window showing a pre-shared secret
4 Click on OK to close the Pre-Shared Secrets window.
5 Click on OK to close the ISAKMP Properties window.
The shared secrets are updated in every workstation pair when you close the
ISAKMP Properties window.
Public Key Infrastructure

FireWall-1 supports public key signatures using the Entrust Public Key Infrastructure
(PKI). The PKI can be configured during FireWall-1 installation or using fwconfig see
(“fwconfig” on page 254 of FireWall-1 Architecture and Administration).
Public Key Configuration
FIGURE 3-8 ISAKMP Public Key Configuration window

In this window, you can generate a key and obtain a certificate for an internal
workstation (that is, a workstation whose Internal field is checked in the General tab
of its Workstation Properties window). In addition, you can specify the matching
criteria for certificates this workstation receives.
Generating Keys and Certificates for Internal Workstations
1 Click on Generate to display the Generate Key window (FIGURE 3-9).
FIGURE 3-9 Generate Key window
2 In the Generate Key window, enter Reference Number and Authorization Code.
This information is obtained when registering to the Entrust PKI.
3 Click on OK (Windows GUI) or Apply (OpenLook GUI).
The following sequence of events then takes place:

■ A key pair is generated.
■ The public part of the key is sent to the Entrust Certificate Authority.
■ The Entrust Certificate Authority computes a certificate.
■ The Entrust Certificate Authority sends the certificate to the FireWall-1
Management Server.
■ The Management Server stores the certificate in the FireWall-1 database.
■ The DN and e-mail fields in the Public Key Configuration window are filled
in by FireWall-1 and disabled (that is, you cannot edit them).
4 In the Public Key Configuration window, optionally check one or more of the
certificate matching criteria (DN, IP address / DNS and e-mail).
Keys and Certificates for External Workstations
1 In the Public Key Configuration window, optionally check one or more of the
certificate matching criteria (DN, IP address / DNS and e-mail).
2 Enter data in the field(s) corresponding to the checked certificate matching

criteria.
For External workstations, Generate is disabled.

Encryption Setup
Encryption Setup — SKIP

OpenLook GUI
FIGURE 3-10 Encryption Setup window — SKIP (OpenLook)
Edit (OpenLook) — Click on Edit to display the Certificate Authority Key window.
In the Windows GUI, there are separate tabs for the Certificate Authority and the
Diffie–Hellman data.
Certificate Authority — select Local, Remote or None

■ If you select Local, then this object’s Management Station is its Certificate
Authority.
■ If you select Remote, choose the object’s Certificate Authority from the
menu. The items in the menu are all the FireWalled objects, with the
exception of this object’s Management Station.
■ If you select None, then there is no Certificate Authority and the keys will
be read from a file with the Read button.
Generate — Click on Generate to generate the object’s key or replace its existing key
(available when Certificate Authority is Local).
Generation Date — the date and time the key was generated
Expiration Date — the date and time the key will expire

Get — Click on Get to get this object’s key from its Certificate Authority (available
when Certificate Authority is Remote).
Read — Click on Read to read this object’s key from a file (available when Certificate
Authority is None).
Caution – The first time you contact a Certificate Authority, its CA public key will be
automatically fetched. However, since this transaction cannot be authenticated, you
will get a warning message. It is recommended that you verify the key just obtained
over the network by some non-network means, such as by fax or telephone.
KeyID — a unique ID (a cryptographic hash function of the public key value)

identifying this object’s key
Object Name — the name of the object with the key (the gateway)
Object Properties — displays the Workstation Properties window for the object given in
Object Name
Scheme — Select an encryption scheme for this object from the menu.
The choices available are those checked in Supported Schemes.
Supported Schemes — list of schemes supported by FireWall-1
Check the schemes to implement for this object.
View — displays the Diffie-Hellman Key Info window (FIGURE 3-18 on page 56)
Write — write the key to a file
If the key has not been initialized when you click on Apply in the Encryption Setup
window, FireWall-1 will attempt to initialize the key, either by generating it or by
fetching it from the appropriate CA. If FireWall-1 is unable to fetch the key from the
CA, a message window will be displayed. If you click on Apply a second time, the
message window will close and the key will remain uninitialized.
Additional SKIP Properties

Additional properties relating to SKIP Encryption are defined in the Control Properties/
Miscellaneous window.

Encryption Setup
Windows GUI - CA Key Tab
FIGURE 3-11 SKIP Properties window - CA Key tab
Local, Remote or None — specifies whether the Certificate Authority is the machine’s
Management Station or some other computer.
Authority.
■ If you select None, then there is no Certificate Authority and the keys will
be read from a file with the Read button.
Generate — Generate the Certificate Authority’s key or replace its existing key
Get — Get the Certificate Authority’s key (available when Certificate Authority is
Remote).
Warning – The first time you contact a Certificate Authority, its CA public key will be

Date — the date and time the key was generated
Exponent and Modulus —These read-only fields make up the actual key.

Windows GUI - DH Key Tab
FIGURE 3-12 SKIP Properties window - DH Key tab
Generate — Generate this object’s Diffie-Hellman key or replace its existing key
Get — Get this object’s Diffie-Hellman key from its Certificate Authority (available
Read — Click on Read to read this object’s key from a file (available when Certificate
Authority is None).

Key — This read-only field is the actual key.
Additional SKIP Properties

Additional properties relating to SKIP Encryption are defined in the Miscellaneous tab
of the Properties Setup window.

Encryption Setup
Encryption Setup — Manual IPSec

There are no object–specific parameters for Manual IPSec encryption. All IPSec
encryption parameters are rule–specific. See “Manual IPSec Encryption Properties” on
page 65 for information on rule–specific Manual IPSec encryption parameters.
FIGURE 3-13 Encryption Setup window — IPSec (OpenLook)

Encryption Setup — FWZ
FIGURE 3-14 Encryption Setup window — FWZ (OpenLook)
In the Windows GUI, there are separate tabs for the Certificate Authority and the
Diffie–Hellman data.
OpenLook GUI
Edit — Click on Edit to display the Certificate Authority Key window.
Certificate Authority — select Local or Remote

Authority.
Generate — click on Generate to generate the object’s key or replace its existing key
(available when Certificate Authority is Local)
Get — Click on Get to get this object’s key from its Certificate Authority (available

Encryption Setup
You cannot get the key of a gateway you have just defined. You must first install
a Security Policy on that gateway and then click on Get to get its key.

Object Name — the name of the object with the key (the gateway)
Object Properties — displays the Workstation Properties window for the object given in
Object Name
Scheme — Select an encryption scheme for this object from the menu.
The choices available are those checked in Supported Schemes.
Supported Schemes — list of schemes supported by FireWall-1
Check the schemes to implement for this object.
View — displays the Diffie-Hellman Key Info window (FIGURE 3-18 on page 56)
If the key has not been initialized when you click on Apply in the Encryption Setup
window, FireWall-1 will attempt to initialize the key, either by generating it or by
fetching it from the appropriate CA. If FireWall-1 is unable to fetch the key from the
CA, a message window will be displayed. If you click on Apply a second time, the
message window will close and the key will remain uninitialized.
Windows GUI - CA Key Tab
FIGURE 3-15 FWZ Properties — CA Key tab

Local or Remote — specifies whether the Certificate Authority is the machine’s

Management Station or some other computer.
Authority.
Generate — Generate the Certificate Authority’s key or replace its existing key
Get — Get the Certificate Authority’s key (available when Certificate Authority is
Remote).
You cannot get the key of a gateway you have just defined. You must first install
a Security Policy on that gateway and then click on Get to get its key.

Exponent and Modulus —These read-only fields comprise the actual key.
Windows GUI - DH Key Tab
FIGURE 3-16 FWZ Properties — DH Key tab
Generate — Generate this object’s Diffie-Hellman key or replace its existing key

Encryption Setup
Get — Get this object’s Diffie-Hellman key from its Certificate Authority (available

Key — This read-only field is the actual key.
Windows GUI - Encapsulation Tab
FIGURE 3-17 FWZ Properties — Encapsulation tab
Encapsulate SecuRemote connections — Encapsulate SecuRemote packets inside

packets with the encrypting gateway’s IP address as the destination.
This option enables a SecuRemote Client to connect to otherwise unreachable

hosts inside the site’s encryption domain. For more information, see “FWZ
Encapsulation” on page 94.

User Encryption Properties
Key Info (FWZ and SKIP)

To display the Key Info window (FIGURE 3-18), click on View in the Encryption Setup
window or in the Encryption tab of the Workstation Properties window (FIGURE 3-14 on
page 52).
FIGURE 3-18 A gateway’s public key
This window displays information about a key, but does not allow modification of this
information, which can be performed only from the Encryption Setup window.
Object Name — the name of the object

identifying this key

The User Encryption Properties window (OpenLook) and the Encryption tab of the User
Properties window (Windows) define the Client Encryption properties for a
SecuRemote user (see Chapter 4, “SecuRemote Server”).
Only the FWZ and ISAKMP encryption schemes are supported for Client Encryption.
Windows GUI
The Encryption tab of the User Properties window defines the Client Encryption
schemes available to a user.
To display the Encryption tab of the User Properties window (FIGURE 3-19):
1 Open the user’s User Properties window.

OpenLook GUI
2 Click on the Encryption tab.
FIGURE 3-19 User Properties window - Encryption tab
Successful Authentication Track — logging option for Encryption attempts
For Client Encryption, the successful authentication tracking is specified in the

Encryption tab of the User Properties window, because successful authentication
and key exchange is possible even if there are no Client Encryption rules.
To enable an encryption scheme for the user, check the box next to the encryption
scheme’s name under Client Encryption Methods.
To define the properties for a scheme, double-click on the icon next to the scheme’s
name. The appropriate Encryption Properties window is opened.
OpenLook GUI
To open the User Encryption Properties window (FIGURE 3-21 on page 60 and
FIGURE 3-20 on page 58), click on Encryption in the User Properties window.
Check the encryption schemes available to this user under Supported Schemes. To
display the parameters for one of the Supported Schemes, select that scheme from
Scheme.
In This Section
ISAKMP Properties page 58

FWZ Properties page 60

ISAKMP Properties
FIGURE 3-20 ISAKMP Properties windows
Note – In the OpenLook GUI, all the relevant fields are in one window. In the Windows
GUI, the relevant fields are divided between two tabs.

ISAKMP Properties
Authentication Tab (Windows GUI)

Check the authentication schemes to be used to authenticate this user for SecuRemote
connections:
■ Password — The user will be authenticated by a password (pre-shared
secret).
If Password is checked, enter the password.

■ Public Key — the user will be authenticated by a public key certificate (PKI)
Encryption Tab (Windows GUI)

In Transform, check one of the following:
■ Encryption + Data Integrity (ESP) — The Security Association will include
both encryption and data integrity (authentication).
■ Data Integrity Only (AH) — The Security Association will include only data
integrity (authentication).
Data Integrity — the cryptographic checksum method to be used for ensuring data
integrity
Choose SHA1 or MD5.
Encryption Algorithm (Windows GUI) or Data Encryption Method (OpenLook GUI) —

the encryption algorithm to be used
Choose one of the available algorithms. You should choose one of the algorithms
available to the SecuRemote Client. If you choose an algorithm stronger than any
of those available to the SecuRemote Client, the connection will fail.
The algorithms available on the SecuRemote Server depend on the FireWall-1

software version and license.
The algorithms available on the SecuRemote Client depend on the SecuRemote

Client software version. To see which versions are available on the SecuRemote
Client, select About from the SecuRemote Client’s Help menu.
TABLE 3-1 lists the available methods on the Client.
TABLE 3-1 Client About SecuRemote window text and encryption methods
text in About box available encryption algorithms

Export 40 bit algorithms (CAST-40 and DES-40CP)
DES DES (in addition to those listed under Export)
Strong 3DES (in addition to those listed under DES and Export)

FWZ Properties
FIGURE 3-21 FWZ Properties window
Session Key Encryption Method — the encryption algorithm for session keys
The available choices depend on the encryption algorithms installed.
You can also choose Clear (meaning no encryption) or Any (meaning the session
key encryption method is chosen by the other party).
Data Encryption Method — the encryption algorithm for communications packets
You can also choose Clear (meaning no encryption) or Any (meaning the data
encryption method is chosen by the other party).
Data Integrity Method —the cryptographic checksum method to be used for ensuring
data integrity
Password Expires After ... Minutes — the number of minutes after which the user will
be asked to re-authenticate by entering the password again
For multiple user passwords, the user enters the same password as before. For
one-time passwords, the user must enter the currently valid password.

Windows GUI
Rule Encryption Properties

The Encryption Properties window defines a rule’s encryption scheme and its
parameters. Note that a rule can only have one encryption scheme.
Windows GUI
1 Double click on a rule’s Encrypt action in the Rule Base Editor.
The General tab of the Encryption Properties window (FIGURE 3-22 on page 61) is
displayed.
2 Select an encryption scheme for the rule from the list and click on Edit.
FIGURE 3-22 Properties window — General tab
The appropriate window will be opened, depending on the scheme you selected.
Protocol Diagnostics — Specifies the action to be taken if protocol errors are detected.
OpenLook GUI
1 Right-click on a rule’s Encrypt action in the Rule Base Editor.
2 Select an encryption scheme for the rule from the Scheme drop-down list.
The bottom part of the window will display the parameters appropriate to the
selected Scheme.
In This Section
ISAKMP/OAKLEY Encryption Properties page 62

SKIP Encryption Properties page 63
Manual IPSec Encryption Properties page 65
FWZ Encryption Properties page 69

ISAKMP/OAKLEY Encryption Properties
FIGURE 3-23 ISAKMP Properties window
The ISAKMP properties in this window define how packets are encrypted. The
ISAKMP properties in the Encryption tab of the Workstation Properties define how the
ISAKMP/OAKLEY key exchange is encrypted.
In Transform, check one of the following:

■ Encryption + Data Integrity (ESP) — The Security Association will include
both encryption and data integrity (authentication).
■ Data Integrity Only (AH) — The Security Association will include only data
integrity (authentication).
Encryption Algorithm — Specifies the encryption algorithm for the traffic.
Data Integrity — Specifies the cryptographic checksum method to be used for ensuring
data integrity.
Peer Gateway — Specifies the gateways with which a gateway encrypting under this
rule is prepared to conduct an encrypted session.
This field can be set to the following values:

■ Any — each gateway is prepared to conduct encrypted sessions with
all other gateways
■ gateway name or group of gateways and/or hosts — each gateway is
prepared to conduct encrypted sessions only with the named gateway
or with a gateway belonging to the given group

SKIP Encryption Properties
In both cases, a gateway is prepared to conduct encrypted sessions with another

gateway only if the packet’s source IP address (for decryption) or destination IP
address (for encryption) is in the other gateway’s encryption domain.
Use Perfect Forward Secrecy — This feature ensures that an eavesdropper who
uncovers a long-term encryption key will be unable to use it to decrypt traffic sent in
the past.
SKIP Encryption Properties

The SKIP Encryption Properties window defines the encryption properties of a SKIP
encryption rule.
FIGURE 3-24 SKIP Encryption Properties window
The SKIP Encryption Properties window’s fields are explained below:
Kij Algorithm — the algorithm used to encrypt the keys used for data encryption and
data authentication
Crypt Algorithm — the data encryption algorithm
MAC Algorithm — the data authentication algorithm

■ Any — FireWall-1 will attempt to find a suitable gateway based on
the defined encryption domains.
■ gateway name — FireWall-1 will conduct encrypted sessions only
with the named gateway.


If both gateways are FireWalled (FireWall-1 is installed on them both), then there
must be two rules — each specifying encryption in one direction — and only one
rule must be installed on each of the gateways.
SKIP Diagnostics Track — Select one of the following:

■ None — no logging or alerting
■ Log — log the event
■ Alert — issue an alert
NSID — Name Space ID, the domain from which Key IDs in the SKIP header are taken
■ None — No Key IDs appear in the header.
■ SKIP MD5 — The KeyIDs are an MD5 hash of the Diffie-Hellman public
keys.
■ IP Address — The KeyIDs are the IP address of the gateway.
IPSec Options — At least one option must be checked.

■ ESP — encrypt
■ AH — authenticate

Manual IPSec Encryption Properties

The Manual IPSec Encryption Properties window (Windows) and the Rule Encryption
Properties window (OpenLook) define the encryption properties of a Manual IPSec
encryption rule.
FIGURE 3-25 Manual IPSec Encryption Properties window (Windows) and the Rule
Encryption Properties window (OpenLook)
The fields in these windows are explained below:
SPI — Security Parameters Index — a number which uniquely identifies a group of

security parameter definitions
Select an SPI from the drop-down list.
In the Windows GUI, the SPIs are defined in the SPI tab of the Manual IPSec
window (FIGURE 3-27 on page 67). For more information, see “Defining an SPI
(Windows)” on page 66.
For information about defining an SPI in the OpenLook GUI, see “Defining an
SPI (OpenLook)” on page 66.
Peer Gateway — Specifies the decrypting gateway. This gateway will be the destination
in the new IP header.

■ Any — FireWall-1 will attempt to find a suitable gateway based on the
defined encryption domains.
■ gateway name — FireWall-1 will conduct encrypted sessions only with the
named gateway.


If both gateways are FireWalled (FireWall-1 is installed on them both), then there
must be two rules — each one specifying encryption in one direction — and only
one rule must be installed on each of the gateways.
Defining an SPI (OpenLook)

In the OpenLook GUI, you can define an SPI from the Rule Encryption Properties
window as follows:
1 Press New SPI.
This is a hexadecimal number (enter leading 0x) and must be greater than
0x100.
2 Enter the SPI number in the pop-up window.
3 Enter the rest of the SPI definition in the Rule Encryption Properties window.
The other fields in the OpenLook window are described in “Defining an SPI
(Windows)” on page 66.
Defining an SPI (Windows)

To define an SPI in the Windows GUI, select Keys from the Manage menu. The
Authentication Keys window (FIGURE 3-26) is displayed.
FIGURE 3-26 Authentication Keys window

Creating a New Key

To create a new key, click on New and select SPI from the menu.
The Manual IPSec window (FIGURE 3-27) is displayed.
Deleting a Key
To delete a key, select the object and click on Remove.
Modifying a Key
To modify a key, select the key and click on Edit, or double-click on the key.
The Manual IPSec window (FIGURE 3-27) is displayed.
FIGURE 3-27 Manual IPSec window
The Manual IPSec window’s fields are explained below:
SPI value — a unique identifying key
This is a hexadecimal number (enter leading 0x) and must be greater than
0x100.
Comment — descriptive text
This text is displayed on the bottom of the Keys window when this key is
selected.
Color — the color of the key’s icon
Select the desired color from the drop-down list.

IPSec Options — At least one option must be checked.

■ ESP — If encryption is defined for this SPI, check ESP and choose an
Encryption Algorithm from the drop-down list.
■ AH — If authentication is defined for this SPI, check AH and choose an
Authentication Algorithm from the drop-down list.
Keys — You can choose to generate a key from a seed, or enter a key manually.
▼ To generate a key from a seed
OpenLook GUI
Check Enable Seed and press Seed.
■ If ESP is checked under IPSec Options, enter an encryption key in Encryption Key.
■ If AH is checked under IPSec Options, enter an authentication key in
Authentication Key.
Windows GUI
Enter a value for Seed and click on Generate.
■ If ESP is checked under IPSec Options, an encryption key is generated and
displayed in Encryption Key.
■ If AH is checked under IPSec Options, an authentication key is generated and
displayed in Authentication Key.
▼ To generate a key manually
OpenLook GUI
Uncheck Enable Seed and enter the key(s) manually.
Authentication Key.
Windows GUI
Enter the key(s) manually.
Authentication Key.
Encryption Key (Hex value) — read-only, unless key was manually generated
Authentication Key (Hex value) — read-only, unless key was manually generated

FWZ Encryption Properties
FWZ Encryption Properties

The FWZ Encryption Properties window defines the encryption properties of an FWZ
encryption rule.
FIGURE 3-28 FWZ Encryption Properties window
The FWZ Encryption Properties window’s fields are explained below:
Session Key Encryption Method — Specifies the encryption algorithm for session keys.
Data Encryption Method — Specifies the encryption algorithm for communications

packets.
You can also choose Clear (meaning no encryption) or Any (meaning the data
encryption method is chosen by the other party).
Data Integrity Method — Specifies the cryptographic checksum method to be used for
ensuring data integrity.

■ Any — each gateway is prepared to conduct encrypted sessions with
all other gateways
■ gateway name or group of gateways and/or hosts — each gateway is
prepared to conduct encrypted sessions only with the named gateway
or with a gateway belonging to the given group

Certificate Authority (FWZ Encryption)

Protocol Diagnostics and Diagnostics Track — Specifies the action to be taken if

protocol errors are detected.
Certificate Authority (FWZ Encryption)

Overview
To display the Certificate Authority Keys window (FIGURE 3-29), click on Edit in the
Encryption Setup window. The Certificate Authority Keys window displays information
about a Certificate Authority’s public key. The information cannot be directly modified
or edited in this window, but a new key can be generated or fetched from the
The data displayed in this window are all public data. No private data are displayed.
FIGURE 3-29 Certificate Authority Key window
Object Name — the name of the object
Scheme — the encryption scheme for the object

New Keys
KeyID — a unique ID identifying this object’s key
This is a cryptographic hash (using MD5) of the public key value, and suffices to
verify the public key when out of band verification is required
Exponent — the exponent part of the CA’s RSA key
Modulus — the modulus part of the CA’s RSA key
New Keys
You can generate or fetch a Certificate Authority’s public key as follows:
■ If the CA is the local Management Station, click on Generate to generate a
new key for the CA.
■ If the CA is external, click on Get to fetch the CA’s public key.
Warning – The first time you fetch the key, it is recommended that you authenticate
it by some other non-network means, such as by fax or telephone.
The local CA key is generated automatically during the FireWall-1 installation. There
is seldom any compelling reason to change it by generating a new key. Moreover,
changing the key requires coordination with remote FireWalls to ensure that they re-
fetch the local key and reload their gateways.
Encrypting Services That Open Back Connections

Some services, for example, FTP and RSH, open back connections on another port.
These back connections are automatically encrypted, and there is no need to define a
rule for this purpose.

Encrypting Services That Open Back Connections

CHAPTER 4
SecuRemote Server
In This Chapter
SecuRemote Implementation page 73

Defining SecuRemote Users page 77
Structure of a SecuRemote Connection page 82
Routing page 86
Step by Step Example page 86
Known Restrictions page 93
FWZ Encapsulation page 94
SecuRemote Implementation
Overview
SecuRemote is composed of software running on the PC, which communicates with a
SecuRemote Server.
For information about the SecuRemote Client software, see Chapter 5, “SecuRemote
Client.”
SecuRemote is implemented on top of a FireWall-1 Virtual Private Network. The

system administrator must first configure a VPN and implement the FireWall-1
Encryption feature, and then extend encryption facilities to nomadic users with the
SecuRemote feature.
To configure SecuRemote, you must:
1 Configure and implement FireWall-1 Encryption on the enterprise network.
If your enterprise network consists of one site only, then configure and
implement FireWall-1 Encryption at that site.
73
2 Define the users that will be allowed access, and specify their means of
authentication.
For information on how to define a SecuRemote user’s means of authentication,

see “Defining SecuRemote Users” on page 77.
Every authentication scheme you select for a user must be enabled on the
FireWall.
3 Install the SecuRemote Client on users’ computers.
For information on installing and configuring a SecuRemote Client, see “Installing

the SecuRemote Client” on page 105.
4 Define rules in the Rule Base that enable SecuRemote users to connect to the
enterprise network.
As in any other case, in order for SecuRemote users to gain access to the
network, there must be a rule in the Rule Base that allows them access. It is not
necessary that there be a specific rule for SecuRemote users. A SecuRemote user
can be allowed access as part of a group of users, some of whom are SecuRemote
users and some of whom are not.
A SecuRemote user’s connection is encrypted when the user makes the

connection using SecuRemote, but is not encrypted when the user makes the
connection without using SecuRemote, as do the other users in the group.
Example
Before SecuRemote is Installed
Suppose that in the network configuration depicted in FIGURE 4-1, Kings is Bob’s PC
and Backs is Alice’s PC.
localnet
Cam-net
Bob
Internet Kings
London
(FireWalled
gateway) Alice
Backs
FIGURE 4-1 SecuRemote Example Configuration

Example
Suppose also that a group Dons has been defined, consisting of Alice and Bob, and
that the following rules in London’s Rule Base allow Alice and Bob access to localnet:
1 Cam_net localnet telnet Accept Short Log Gateways

2 Dons@Cam_net localnet ftp UserAuth Short Log Gateways
These rules specify that Alice and Bob can freely use TELNET on localnet, but they can
use FTP only after User Authentication. It doesn’t matter from which PC each user
connects. Bob can connect from Alice’s PC and vice versa, provided they use their own
names for the authentication process.
After SecuRemote is Installed

Suppose that Bob installs the SecuRemote Client on his PC (Kings) and defines London
as a site. This has the effect of encrypting connections between Kings and the defined
sites (because SecuRemote is an attribute of a PC, not of a user). Bob can continue to
use FTP and TELNET on localnet from Kings under the same rules, but the connection
will be encrypted, provided all the following conditions are met:
1 London’s encryption domain includes localnet.
2 London’s encryption domain is exportable.
3 On Kings, London is defined as a site.
If any of these conditions is not true, then the connection will not be encrypted.
When Bob attempts to use FTP on localnet from Kings, he will be authenticated twice:
the first time by SecuRemote on Kings (the SecuRemote Client on the PC asks Bob to
enter his password, but it is the FireWall that verifies it) and the second time by the
FireWall on London (as the Rule Base specifies).
Bob can also connect from Alice’s PC (Backs), but in this case the connection will not
be encrypted, because SecuRemote is not installed on Backs. The same situation
applies to Alice — if she connects from Kings, the session will be encrypted, but if she
connects from Backs it will not.
Next, suppose London’s system administrator changes the Action in the second rule to
Client Encrypt, as follows:
1 Cam_net localnet telnet Accept Short Log Gateways

2 Dons@Cam_net localnet ftp Client Encrypt Short Log Gateways
Chapter 4 SecuRemote Server 75

TABLE 4-1 summarizes how Alice and Bob use TELNET and FTP on localnet.
TABLE 4-1 How Alice and Bob connect
user computer TELNET connects under ... and FTP ...

Bob Kings the first rule, and the session is connects under the second rule,
(SecuRemote installed) encrypted and the session must be
encrypted
Bob Backs the first rule, and the session is cannot connect, because the
not encrypted because there is session must be encrypted but
no SecuRemote on Backs there is no SecuRemote on
Backs
Alice Kings the first rule, and the session is connects under the second rule,
(SecuRemote installed) encrypted and the session must be
encrypted
Alice Backs the first rule, and the session is cannot connect, because the
not encrypted because there is session must be encrypted but
no SecuRemote on Backs there is no SecuRemote on
Backs
The effect of the Client Encryption rule is to force the connection from Kings to be
encrypted. Without the Client Encryption rule, the connection would not be encrypted
if one of the required conditions were not true (see “After SecuRemote is Installed” on
page 75).

Windows GUI
Defining SecuRemote Users
Note – This section describes how to configure users with the Windows and OpenLook
GUIs. See Check Point Account Management Client for information on configuring
users on an LDAP Server.
In This Section
Windows GUI page 77

OpenLook GUI page 80
Windows GUI
To define a SecuRemote user’s authentication and encryption properties, proceed as
follows:
1 Open the Users window (FIGURE 4-2) by:

■ choosing Users from the Manage menu, or
■ clicking on in the toolbar.
FIGURE 4-2 Users window
2 Open the User Properties window (FIGURE 4-3 on page 78) for the user by:
■ double-clicking on the user, or
■ selecting the user and clicking on Edit.

FIGURE 4-3 User Properties window — General tab
Note – For FWZ encryption, a user’s authentication method is defined in the

Authentication tab. For ISAKMP encryption, the user’s authentication method is
defined in the Encryption tab. Encryption properties for both FWZ and ISAKMP
encryption are defined in the Encryption tab.
A user can have both FWZ and ISAKMP encryption defined.
3 If the user’s encryption scheme will only be ISAKMP, proceed to “ISAKMP

Properties” on page 80.
FWZ Authentication Properties

4 Display the user’s Authentication tab (FIGURE 4-4).
FIGURE 4-4 User Properties window — Authentication tab showing S/key Authentication
5 Choose an Authentication Scheme for the user.
Having defined how the user will be authenticated for FWZ, you must next define
the encryption properties of the user’s SecuRemote connections.

Windows GUI
6 Display the user’s Encryption tab (FIGURE 4-4).
FIGURE 4-5 User Properties window — Encryption tab
7 To enable an encryption scheme for the user, check the box next to the
encryption scheme’s name under Client Encryption Methods.
8 To define the properties for a scheme, double-click on the icon next to the
scheme’s name. The appropriate Encryption Properties window (FIGURE 4-6 or
FIGURE 4-7) is displayed.
FWZ Properties
FIGURE 4-6 FWZ Properties window
For information about the FWZ Properties window, see “FWZ Properties” on
page 60.

ISAKMP Properties
FIGURE 4-7 ISAKMP Properties windows
For information about the ISAKMP Properties window, see “ISAKMP Properties”
on page 58.
OpenLook GUI
To define a SecuRemote user’s authentication and encryption properties, proceed as
follows:
1 Open the Users Manager window.
FIGURE 4-8 Users Manager window

OpenLook GUI
2 Open the User Properties window (FIGURE 4-9), double-click on a user name in
the Users Manager window (FIGURE 4-8 on page 80).
FIGURE 4-9 User Properties window - S/Key Authentication
3 If the user’s encryption scheme will only be ISAKMP, proceed to “Encryption

Properties” on page 82.
Note – A user can have both FWZ and ISAKMP encryption defined.
FWZ Authentication Properties

4 Choose an Authentication Scheme for the user.
Having defined how the user will be authenticated for FWZ, you must next define
the encryption properties of the user’s SecuRemote connections.

Structure of a SecuRemote Connection
To display the User Encryption Properties window (FIGURE 4-10), click on Encryption in
the User Properties window (FIGURE 4-9 on page 81).
FIGURE 4-10 User Encryption Properties windows (FWZ and ISAKMP)
For information about FWZ properties, see “FWZ Properties” on page 60.
For information about ISAKMP properties, see “ISAKMP Properties” on page 58.

Topology
Before a SecuRemote connection can take place, the SecuRemote Client must obtain
the topology of the site to which it will connect. There are two ways the Client can
obtain a site’s topology:
■ A user can define a site and download the topology.
See “Defining Sites” on page 111 for information on how to define sites on the
SecuRemote Client.
■ The System Administrator can install a standard userc.c file for SecuRemote
users, pre-defining sites for them. In this way users do not have to download the
topologies of the sites to which they will be connecting.
The SecuRemote Client stores the topologies it knows about in the userc.c file. It is
only necessary for a SecuRemote Client to download a site’s topology when the
topology changes.

Topology
Topology Download
In Versions 4.0 and higher of the SecuRemote Client and Server, a site’s topology may
be downloaded to a SecuRemote Client in encrypted format. Earlier versions did not
encrypt the topology download.
If you are using a pre-Version 4.0 SecuRemote Client with a Version 4.0 or higher
SecuRemote Server, check the Respond to unauthenticated cleartext topology requests
option in the Encryption tab of the SecuRemote Server’s Workstation Properties
window. The SecuRemote Server will then download topology in unencrypted format to
pre-Version 4.0 SecuRemote Clients.
If the Respond to unauthenticated cleartext topology requests option is not checked,

pre-Version 4.0 SecuRemote Clients will be unable to obtain the site’s topology.
The topology information also indicates whether a gateway supports FWZ or ISAKMP
or both. For gateways that support both FWZ and ISAKMP, the method used depends
on the settings in the Options window of the SecuRemote Client (see TABLE 4-3 on
page 85).
Note – System administrators can ensure that all company personnel have the same
site configuration for SecuRemote by copying a standard userc.c file to the
installation diskette set. It is also possible to supply FWZ and ISAKMP users with
different userc.c files.

Authentication
The first time a SecuRemote Client initiates a connection to a site (and also whenever
a password expires), the user must first authenticate himself or herself to the
SecuRemote Server. The authentication method used depends on the encryption
method used for the connection.
FIGURE 4-11 SecuRemote Client User Authentication and Password windows
Encryption Method
The encryption method used depends on the encryption methods supported by the
SecuRemote Client and SecuRemote Server.
Versions 4.0 and higher of the SecuRemote Client support both FWZ and ISAKMP.
Earlier versions support FWZ only.
TABLE 4-2 lists the encryption methods supported by SecuRemote Servers.
TABLE 4-2 Encryption Method Supported
type of SecuRemote Server encryption methods supported

FireWall-1
■ Version 4.0 and higher — ISAKMP and FWZ
■ pre-Version 4.0 — FWZ only

VPN-1 Secure Center ISAKMP only

Authentication
TABLE 4-3 lists which encryption method is used for a given connection.
TABLE 4-3 Encryption Method Used
If the SecuRemote
Server supports ... then the method used is ...
FWZ and ISAKMP
■ SecuRemote Client Version 4.0 and higher — the method
specified under Default Key Scheme in the SecuRemote
Client’s Options window
■ SecuRemote Client pre-Version 4.0 — FWZ

FWZ only FWZ
ISAKMP only ISAKMP (SecuRemote Client Version 4.0 and higher)
Authentication Methods
There are several possible authentication methods:
FWZ
1 FWZ — any of the authentication schemes supported on the SecuRemote Server:
password, S/Key, RADIUS etc.
In the Password window, the user enters his or her user name and the password,
in accordance with the Authentication Scheme specified in the Authentication
tab of the User Properties window.
If the password is not entered, the user will be prompted for it.
If the encryption method is FWZ, the authentication is encrypted using Diffie-

Hellman keys.
ISAKMP
2 pre-shared secret (ISAKMP)
The SecuRemote Client and SecuRemote Server authenticate each other by

verifying that the other party knows the pre-shared secret, which is the user’s
password (as defined in the Authentication tab of the user’s ISAKMP Properties in
window). The user enters his or her user name in User and the pre-shared secret
in Password.

Routing
3 certificates (ISAKMP)
The user checks Use Certificate, enters an Entrust profile file name and a
Password to access the certificate.
The SecuRemote Client authenticates itself to the SecuRemote Server by using its
certificate. The SecuRemote Server verifies the certificate against a revocation
list. The SecuRemote Server authenticates itself by sending the SecuRemote
Client its certificate and a copy of a valid revocation list, signed by the
Key Exchange
Once the user has been authenticated, the SecuRemote Client and SecuRemote Server
exchange encryption keys, in preparation for encrypting the actual connection. The
method of key exchange depends on the encryption scheme used: FWZ or ISAKMP.
Connection
After encryption keys have been exchanged, the connection begins. The connection is
encrypted according to the encryption scheme used: FWZ or IPSec (for ISAKMP).
Routing
The default routing must ensure that reply packets (returning to the SecuRemote client)
are routed through the same encrypting gateway through which the original packets
were routed.
If this is not the case, then one way to force reply packets back through the gateway
is to perform Address Translation on the gateway, hiding all outside addresses (those
addresses not in the internal network) behind the gateway. The internal hosts will see
the packet as having originated on the gateway, and will direct the reply packets to the
gateway.
This solution is most suitable when a single gateway is dedicated to handling

SecuRemote sessions.
Warning – The IP address of a gateway’s external interface must never be hidden.
Step by Step Example

Configuring the Network
To implement SecuRemote, proceed as follows:
1 Configure and implement a VPN, as described in Chapter 2, “Configuring

FireWall-1 Encryption.”

Defining Users
2 For each SecuRemote server:

■ Check the Exportable checkbox in its Workstation Properties window.
This indicates that the information about the SecuRemote Server

(specifically, its encryption domain) is to be made available to any
SecuRemote client that requests the information.
■ Specify the FWZ or ISAKMP/OAKLEY method in the Encryption tab of the
Workstation Properties window (Windows GUI) or Key Management
window (OpenLook GUI).
See “Workstation Encryption Properties” on page 39 for information on

these windows.
■ Specify the properties for each scheme in the FWZ Properties and ISAKMP
Properties windows (Windows GUI) and Key Management window
(OpenLook GUI).
See “Workstation Encryption Properties” on page 39 for information on

these windows.
■ Enable the authentication schemes used by FWZ SecuRemote users in the
Authentication tab of the Workstation Properties window (Windows GUI) or
in the Host Authentication Schemes window (OpenLook GUI).
See “Workstation Properties Window — Authentication Tab” on page 28 of

Managing FireWall-1 Using the Windows GUI or “Auth. Schemes” on
page 29 of Managing FireWall-1 Using the OpenLook GUI.
Defining Users
3 Define the users who will be using the SecuRemote Client. You can define users
either with the FireWall-1 GUI or with the FireWall-1 Account Management
Client.
■ For example, suppose Alice and Bob (whose user names are alice and bob
respectively) will be SecuRemote clients, then define a user group called
SR_users and add them to the group.
■ If you are defining the user with the FireWall-1 GUI, then for certificate
users, the user name must be the “commonname” (cn) in the certificate.
Embedded spaces are significant.
■ For each user, specify the authentication method(s) and encryption
properties.
See “Defining SecuRemote Users” on page 77 for information on defining

SecuRemote users.
Note – For Client Encryption, the encryption properties are defined per user. In
contrast, for Encryption, the encryption properties are defined per rule.

Rule Base
4 If you wish to force SecuRemote users to always use SecuRemote when they
connect to the enterprise network, then you must define a rule whose Action is
Client Encrypt, for example:
SR_users@Any localnet tenet Client Encrypt Short Log Gateways
This rule indicates that when users sr_alice and sr_bob attempt a TELNET
session with localnet, then the Action is Client Encryption.
■ Source is the user group defined above.
■ Destination is (an object in) the encryption domain of the rule’s
Installed On object.
■ In the rule above, localnet is in SR_GW’s encryption domain.
Services has a unusual meaning in this context. All communications between the
SecuRemote Client and the encryption domain of the SecuRemote Server are
encrypted, but the Services listed in the rule are authenticated as well.
If you double-click on a Client Encryption rule’s Action, the Client Encryption

Properties window is displayed.
FIGURE 4-12 Client Encryption Properties window (OpenLook) and User Encryption Action
Properties window (Windows)
In this window, the fields have the same meaning as in the Rule Authentication
Properties window for a User Authentication rule.
Source — reconcile Source in the rule with Allowed Sources in the User
Properties window.

Rule Base
The Allowed Sources field in the User Properties window may specify that
the user to whom this rule is being applied is not allowed access from the
source address, while the rule may allow access. This field indicates how to
resolve this conflict.
■ Choose Intersect with User Database to apply the intersection of the
access privileges specified in the rule and in the User Properties
window.
■ Choose Ignore User Database to allow access according to the Source
specified in the rule.
Destination — reconcile Destination in the rule with Allowed Destinations in the

User Properties window.
The Allowed Destinations field in the User Properties window may specify
that the user to whom this rule is being applied is not allowed access to the
destination address, while the rule may allow access. This field indicates
how to resolve this conflict.
■ Choose Intersect with User Database to apply the intersection of the
access privileges specified in the rule and in the User Properties
window.
■ Choose Ignore User Database to allow access according to the
Destination specified in the rule.
Specifying Client Encrypt as the action means that only SecuRemote Clients can
communicate under the rule, and that the authentication is handled
automatically by the SecuRemote Client and Server transparently to the user.
Client Encryption provides a higher level of security than User Authentication.
5 Install the Security Policy.
6 Install Check Point SecuRemote on each PC that will be using SecuRemote to

communicate with the enterprise network.
7 Configure each SecuRemote PC (see Check Point SecuRemote Client for

information on how to do this).
installation diskette set.

Destination
A Client Encryption rule applies to packets whose destination is in both:
■ the object(s) appearing under Destination in the rule
■ the encryption domain of the FireWall through which the connection is made
(which is one of the FireWalls listed under Install On in the rule)
Tom's
Encryption
Domain
Tom
FireWalled
Gateway
Internet
SecuRemote
User Jerry
FireWalled
Gateway
Jerry's
Encryption
Domain
FIGURE 4-13 Two FireWalls and Encryption Domains
Consider the following rule:
SR_users@Any localnet Any Client Encrypt Short Log Tom, Jerry
This rule applies to sessions with computers in Tom’s encryption domain if the
connection is through Tom, and to sessions with computers in Jerry’s encryption
domain if the connection is through Jerry. This is true even though the encryption
domains are part of the same network. However, if the connection is through Tom to
one of the computers in Jerry’s encryption domain, then the rule does not apply. This
means that the session will not be allowed unless there is another rule in the Rule Base
that allows it.

Other FireWalls
Other FireWalls
Services
If there are other firewalls along the path connecting the SecuRemote Client (that
performs the encryption) and the SecuRemote Server (the FireWall that performs the
decryption), you should configure the other firewalls to allow FW-1 services to pass
from the SecuRemote Client to the SecuRemote Server.
For FWZ, you should also allow RDP (UDP on port 259). For ISAKMP, you should
allow IPSEC, which includes ISAKMP (UDP on port 500).
To allow these services, proceed as follows:
1 If the other FireWalls are prior to Version 2.1, add a rule to the Rule Base that
allows anyone to access the server’s RDP service.
2 On the other FireWalls’ Management Servers, define the SecuRemote Server to be

a FireWalled gateway (or host).
If this is not possible, add a rule on the other FireWalls which allow anyone to
access the above services.
Address Translation
If a firewall along the path connecting the SecuRemote Client and the SecuRemote
Server translates the SecuRemote Client’s IP address so that the SecuRemote Server
does not see the SecuRemote Client’s true IP address, SecuRemote will not function
properly.
Current Restrictions
Version 4.0 of Check Point SecuRemote imposes certain restrictions, which will be
removed in future versions of FireWall-1.
VPN Configuration
SecuRemote requires that the VPN be configured so that both of the following
conditions are true:
■ The encryption domains of all the SecuRemote servers in the VPN do not overlap
(that is, no host is included in more than one encryption domain).
■ If there is more than one FireWall along the path from a SecuRemote client to its
destination, then only one of the FireWalls can be a SecuRemote server for the
connection.
Violations of these restrictions are reported by the SecuRemote Clients that encounter
them.

Control Properties (Properties Setup)

Some services provided by a server inside an encryption domain must be specially
configured for SecuRemote users in the Control Properties window (OpenLook) or the
Properties Setup window (Windows), as follows:
FTP
Enable the following options:
■ Enable Response of FTP Data Connections (First)
■ Enable FTP PASV Connections (First)
RealAudio
Enable the following option:
■ Enable RealAudio Reverse Connections (First)
VDOLive
Enable the following option:
■ Enable VDOLive Reverse Connections (First)
RPC
If the server is inside an encryption domain, then the only way to allow a SecuRemote
user to access an RPC service under a rule whose Action is Client Encrypt is to specify
Any under Services in the rule. For example, the following rule will allow SecuRemote
access to NFS services:
All_users@Any NFS-Server Any Client Encrypt Short Log SR_GW
This rule, on the other hand, will not allow SecuRemote access to NFS services, though
all other users will be allowed access:
Any NFS-Server NFS-group Client Encrypt Short Log SR_GW
To allow access, either define a rule as shown above, or disable the SecuRemote Client.
This anomaly will be corrected in a future version of FireWall-1.

Current Restrictions
Known Restrictions
Timeout
The first time the user connects to a site, it may happen that the delay introduced by
entering a user name and password may cause the application (for example, TELNET)
to timeout. In this case, the user should simply restart the application.
Data Not Encrypted

The following data are never encrypted:
■ The connection between the PC and the Manager when performing an Add New
Site or Update operation.
However, the information is signed.

■ The connection between the PC and a SecuRemote Server in which a key is
exchanged.
However, the information is signed and the password and the session key are
encrypted.
■ DNS information (but see “DNS” on page 97 for information on how to encrypt
DNS)
■ In FTP, RealAudio, and VDOLive connections, some packets are not encrypted.
These packets contain the information needed to open a back connection from
the SecuRemote Server to the PC.
■ Local connections are not encrypted.
A connection is “local” if both the IP Address of the PC (Client) and the IP

Address of the destination (server) are both inside the same Encryption Domain
of the same SecuRemote Server.
TCP Stacks
The following TCP/IP stacks are supported:
■ MS TCP (Microsoft)
User Password
The user password is limited to 8 characters.
FireWall-1 Adapters
Only one FW-1 Adapter can be added or removed in one session of the Control Panel
Network applet.

FWZ Encapsulation
Power Management
On some computers, SecuRemote connectivity can be lost when the computer returns
from Suspend mode. A message stating that a fatal exception in VXD FWMAC(01)
occurred is displayed when this happens.
To resume connectivity, reboot the computer.
Modifying the Network Configuration after Installing SecuRemote

Consider the following scenario:
1 You have several adapters but you have defined only one TCP/IP protocol, which
is of course bound to only one of the adapters.
2 You install SecuRemote.
As a result, the SecuRemote adapter and protocol (FW-1 adapter and FW-1
protocol) is placed in between your TCP/IP protocol and the original adapter.
3 You install the TCP/IP protocol on the other adapters.
In this case, proceed as follows:
1 Uninstall SecuRemote.
2 Add the new TCP/IP protocols.
3 Re-install SecuRemote.
FWZ Encapsulation
This section describes encapsulation between a SecuRemote Client and a FireWall-1
SecuRemote Server when FWZ encryption is used.
This section does not apply to VPN-1 Secure Center SecuRemote Servers, which do not
support FWZ. VPN-1 Secure Center supports only ISAKMP, under which packets are
encapsulated by IPSec.

How FWZ Encapsulation Works
How FWZ Encapsulation Works

The figure below shows a SecuRemote user (Alice) connecting to a host inside London’s
encryption domain.
London's
Encryption
Domain
BigBen
Alice London
Tower
Internet
SecuRemote FireWalled
User Gateway Thames
FIGURE 4-14 SecuRemote user connecting to a host inside a site’s encryption domain
The connection begins when, for example, the user at Alice types:
telnet Thames
or:
telnet IPaddress
This initiates a key exchange with London (the gateway), after which the first TELNET
packet is sent to Thames.
However, if Thames is not reachable from Alice (perhaps because Thames has an
invalid IP address1) then it is still possible for Alice to conduct a SecuRemote session
with Thames using encapsulation.
Suppose Alice attempts to initiate a TELNET session with Thames.
1 Although Alice does not know how to contact Thames, Alice does know that
Thames is in London’s encryption domain, so Alice initiates a key exchange
session with London.
If necessary, Alice first asks the user to authenticate himself or herself in the
usual way.
1.If the problem is an invalid IP address, then another solution might be FireWall-1’s Network Address
Translation feature. See Chapter 5, “Network Address Translation,” of FireWall Architecture and
Administration for more information.

FWZ Encapsulation
2 If the Encapsulate SecuRemote connections field in London’s Key Management

window is checked, London instructs Alice to encapsulate all packets it sends to
hosts in London’s encryption domain.
3 Alice encapsulates the initial TELNET packet inside another packet (with
destination IP address London) and sends the encapsulated packet to London.
The encapsulation consists of replacing the IP address and appending the original
IP address at the end of the packet, increasing its length by 5 bytes (the
appended IP address is not in cleartext).
4 London extracts the original packet from the encapsulated packet and sends it to
Thames.
5 Thames sends a reply packet (with source IP address Thames and destination IP
address Alice).
6 London intercepts the reply packet and encapsulates it inside another packet
(with source IP address London and destination IP address Alice), and sends it
on.
7 Alice receives the encapsulated reply packet and extracts the original reply
packet.
The communication continues in this way, with Alice and London encapsulating and
de-encapsulating packets. As they pass through the Internet, these packets appear to
be part of a communication between Alice and London, but the communication is
actually between Alice and Thames.
Note – Encapsulation is supported by FireWall-1 Version 3.0a and higher, and by

SecuRemote Version 3.0 and higher.

Implementing Encapsulation
Implementing Encapsulation
To implement encapsulation, check the Encapsulate SecuRemote connections in the
encapsulating gateway’s Key Management window (OpenLook GUI) or in the
Encapsulation tab of its FWZ Encryption Properties window (Windows GUI).
FIGURE 4-15 FWZ Encryption Properties — Encapsulation tab (Windows GUI)
TABLE 4-4 lists what happens for various combinations of the Encapsulate SecuRemote
connections field and the SecuRemote version.
TABLE 4-4 Combinations of the Encapsulate SecuRemote connections Field and the
SecuRemote Version
Encapsulate
SecuRemote SecuRemote Version pre-Version
connections SecuRemote Version 3.0 and higher 3.0
checked The key exchange session will time out
on the SecuRemote client, and there
The communication will be encapsulated.
will be an error indication on the
gateway.
not checked The communication will not be The communication will not be
encapsulated, and if the host is encapsulated, and if the host is
unreachable, connections will time out. unreachable, connections will time out.
DNS
The scenario under which encapsulation takes place leaves the following question
unanswered: If the destination machine has an illegal IP address, who resolves its
name?
The best solution is to configure the SecuRemote Client’s primary DNS as an internal
DNS server that can resolve internal names with illegal IP addresses. It’s best to
encrypt the DNS resolution of these internal names, but you will probably not want all
DNS traffic to be encrypted, because this would mean that every DNS resolution
would require authentication.

FWZ Encapsulation
To solve this problem, proceed as follows:
1 Modify the $FWDIR/conf/dnsinfo.C file on the Management Station to

redirect DNS by providing the following information.
■ the internal DNS server’s IP address
■ the domain for which it resolves names
■ the maximum number of labels to resolve (for example, 3 for
xxx.hello.com)
Suppose the SecuRemote Client’s domain is .hello.com and it fails to

resolve yyy.goodbye.com. By default, Windows will then try to resolve
yyy.goodbye.com.hello.com, and you will probably not want this query
to be encrypted.
■ the network addresses for which it resolves (for reverse DNS)
2 In $FWDIR/conf/dnsinfo.C, set :encrypt_dns (true) under :dnsinfo.
3 Instruct the gateway to encrypt DNS by changing the definition of

USERC_DECRYPT_SRC in crypt.def.
4 On the SecuRemote Client, set :dns_encrypt (true) under :options in

database\userc.C.

DNS
Example
$FWDIR/conf/dnsinfo.C file on the Management Station
:dns_servers (
: (bigben.london
:obj (
: (192.204.75.192)
)
:topology (
: (
:ipaddr (192.204.75.0)
:ipmask (255.255.255.0)
)
)
:domain (
: (
:dns_label_count (3)
:domain (.hello.com)
)
)
)
)
:encrypt_dns (true)
$FWDIR/lib/crypt.def file on the Management Station
#define ENCDNS
define USERC_DECRYPT_SRC {
(
#ifndef ENCDNS
not(dport = SERV_domain, (udp or tcp)),
#endif
not(dport = FWD_SVC_PORT, tcp),
not(dport = FWM_SVC_PORT, tcp),
not(dport = ISAKMPD_DPORT, sport = ISAKMPD_SPORT, udp)
)
};

FWZ Encapsulation
$FWDIR\database\userc.C on the SecuRemote Client
(
:options (
:dns_xlate (true)
:dns_encrypt (true)
)
)

SecuRemote Error Messages
SecuRemote Error Messages

TABLE 4-5 SecuRemote Errors
Error Message Meaning Course of Action

“Internal problem” SecuRemote encountered an Make a copy of the entire message
unexpected problem. and pass it on to your system
administrator.
“No answer received from a SecuRemote is unable to make Verify that you are using the correct
FireWall … at site …” a connection to the indicated user name and password and then
FireWall. try to reconnect.
“Communication with site … SecuRemote is unable to make Try to ping the site. If this fails,
has failed” a connection to the indicated notify your system administrator.
site.
“Site … has failed to sign its There is a problem with the Notify your system administrator.
message” site’s signature.
“Site… says that it is not a The site does not identify Verify that you have the correct
Certificate Authority” itself as a Certificate IP address for the site, and confirm
Authority. with the site’s system administrator
that the site is indeed a FireWall-1
Management Station.
If the site does not support FWZ,
then uncheck Respond to
unauthenticated cleartext
topology requests option in the
Encryption tab of the SecuRemote
Server’s Workstation Properties
window.
“Site …has failed on error SecuRemote encountered an Notify your system administrator.
…” unexpected problem.
“Site … has changed. “ The SecuRemote Client’s Update the site.
information about the site is
out-of-date.
“The IP address (…) of site Two sites have the same IP Delete the incorrect one.
… is the same as the IP address.
address of site …”

FWZ Encapsulation
TABLE 4-5 SecuRemote Errors

“Site … has at least two There is an error in the Notify your system administrator.
gateways with an configuration.
overlapping Encryption
Domain”
“Driver not found “ The driver could not be found. Check your network configuration
and reinstall SecuRemote.
If this message persists, uninstall
SecuRemote and contact your
system administrator for further
assistance.
“Database was corrupted” The SecuRemote Client’s site Delete the userc.c file and
database has been corrupted redefine all your sites.
and is no longer usable.

CHAPTER 5
SecuRemote Client
In This Chapter
SecuRemote Client page 103

Installing the SecuRemote Client page 105
Uninstalling the SecuRemote Client page 108
Using the SecuRemote Client page 111
Certificates page 122
Properties page 124
Closing the SecuRemote Daemon page 125
Single SignOn page 125
SecuRemote Client Menus page 127
SecuRemote Client Toolbar page 130
SecuRemote Client
The SecuRemote is Clients consists of a kernel module and a daemon.
SecuRemote Kernel Module

The SecuRemote kernel module is an NDIS3.1 driver, installed between the TCP/IP
stack and adapter already in use, which filters all TCP/IP communication passing
through the PC. The module behaves as both an “adapter” and a “transport”
connected back-to-back. Using the NDIS3.1 standard makes it possible to interface to
any TCP/IP stack or adapter using the same standard.
Initially, the TCP/IP stack (transport) is bound to a “real” adapter, for example, a dial-
up or Ethernet adapter. The SecuRemote kernel module is installed by first unbinding
the TCP/IP stack from the real adapter and then binding the TCP/IP stack to the
103
SecuRemote Client
adapter side of the SecuRemote kernel module and at the same time binding the
transport side of the SecuRemote kernel module to the real adapter. This is done
automatically by the installation program, but it can be manually reconfigured.
Before SecuRemote Installation After SecuRemote Installation

“real” protocol “real” protocol
“real” adapter FW-1 adapter
hardware card FW-1 protocol
“real” adapter
hardware card
FIGURE 5-1 Network configuration before and after SecuRemote installation
The SecuRemote kernel can determine if an outgoing or incoming packet is going to or

coming from an encryption domain and so should be encrypted or decrypted.
The SecuRemote kernel also knows with which SecuRemote Server the encryption will
take place, and invokes the daemon in order to exchange a key with the SecuRemote
Server.
SecuRemote Daemon
The SecuRemote daemon is a Win32 application that is run when Windows starts up
and until the user logs out. The SecuRemote daemon performs the following functions:
1 Loads the SecuRemote kernel with information about all SecuRemote Servers and
their encryption domains.
2 Provides a Graphic User Interface (GUI) by which the user can add, update and
remove sites.
This is done by communicating with the site’s Certificate Authority. The

communication is signed with an RSA key.
3 Maintains the site list and assigns a user name and password to each site.
4 Exchanges a session key with a SecuRemote Server.
The key exchange is initiated by the SecuRemote kernel module. If necessary, the
SecuRemote daemon asks the user for a name and password, and after verifying
them with the SecuRemote Server, exchanges a session key with the SecuRemote
Server and loads it into the SecuRemote kernel.
When the SecuRemote Kernel Module Starts

When Windows is loaded, the SecuRemote kernel module is loaded and bound between
the TCP/IP stack and the adapter, and its internal tables are initialized.
104 Check Point SecuRemote Client • September 1998

When the SecuRemote Daemon Starts
When the SecuRemote Daemon Starts

When the daemon starts, it loads a list of addresses with which it should conduct
encrypted sessions (the encryption domains of all the SecuRemote Server of which it is
aware) into SecuRemote kernel.
As the User Works

The user can then freely use the Internet. However, when the user connects to one of
the sites in the database (or a host in one of the encryption domains), the kernel
module “wakes up” the daemon. Next, the daemon:
■ Holds the first packet without transmitting it.
■ Examines the packet and determines the responsible site, and the SecuRemote
Server in the site.
■ Challenges the user to authenticate himself or herself.
■ Initiates a key exchange protocol with the SecuRemote Server.
■ Encrypts the first packet and transmits it.
After this happens, everything the PC sends to the SecuRemote Server’s encryption
domain is encrypted.
For more information, see “Encryption Setup” on page 41.
Installing the SecuRemote Client

Minimum Installation Requirements
TABLE 5-1 lists the minimum hardware and operating system requirements for the
Check Point SecuRemote Client.
TABLE 5-1 Minimum Requirements (GUI Client)
Platforms Windows 95, Windows NT (Intel only)

Disk space 6 Mbytes
Windows 95 — 16 Mbytes
Memory Windows NT — 32 Mbytes
Chapter 5 SecuRemote Client 105

Installing the SecuRemote Client
Installation Procedure
Note – If you have an older version of SecuRemote installed on your PC, remove
(uninstall) it according to the instructions supplied with that version.
1 Confirm that TCP/IP is working properly.
You can do this by pinging a host you know is accessible from your PC. If the
ping is successful, then TCP/IP is working properly.
2 For Windows NT only, stop the SecuRemote Server if it is running on this

machine.
For information on how to stop the SecuRemote Server, see:

■ “fwstop” on page 108 of VPN-1 Secure Center Administration(if the
SecuRemote Server is Check Point VPN-1 Secure Center)
■ “fwstop” on page 256 in FireWall-1 Architecture and Administration (if the
SecuRemote Server is Check Point FireWall-1)
The SecuRemote Server does not run on Windows 95.
3 If you have the original Check Point SecuRemote Client media, insert it in the
drive.
If you have downloaded the SecuRemote executable, copy it to a temporary

directory and execute it. The file will self-extract.
site configuration for their SecuRemote Clients by copying a standard userc.c file to
the installation diskette set. The userc.c file is not compressed on the diskette, and
the default file is an empty file.
4 Open the Start Menu and choose Settings.
5 Choose Control Panel from the Settings menu.
6 Double click on Add/Remove Programs and follow the instructions.
Alternatively, you can open the Start Menu and choose Run, and then run the
SETUP application on the disk.
7 If a SecuRemote Server is running on your computer (NT only), a warning

message is displayed.

Installation Procedure
8 If Check Point SecuRemote Client is already installed on your computer, you will
be asked whether you wish to overwrite the existing configuration or update it
(FIGURE 5-2).
FIGURE 5-2 Existing Version Found window
9 The Choose Destination Location window (FIGURE 5-3) allows you to specify a
directory in which Check Point SecuRemote Client will be installed by selecting
Browse.
FIGURE 5-3 Choose Destination Location window
If you do not choose a directory, then Check Point SecuRemote Client will be installed
in the default directory, indicated under Destination Directory.

Uninstalling the SecuRemote Client
10 When the installation completes, you will be asked whether you wish to restart
the computer.
The new configuration will take effect only after you restart the computer.
11 At this point, you can delete all the files from the temporary directory.
After you have restarted your computer, your first step should be to define at least one
site so that you can begin to use SecuRemote to encrypt your communications. For
information on how to define sites, see “Using the SecuRemote Client” on page 111.

▼ To uninstall the SecuRemote Client
1 Open the Windows Start menu and choose Control Panel.
2 Double-click on Add/Remove Programs.
3 Select SecuRemote (FIGURE 5-4).
FIGURE 5-4 Uninstalling SecuRemote
4 Click on Add/Remove.
5 Click on OK.

After Installing
After Installing
Removing or Moving the SecuRemote Files
Do not remove or move the SecuRemote files manually. If you wish to remove the files,
uninstall SecuRemote (see “Uninstalling the SecuRemote Client” on page 108). If you
wish to move the files to another directory, reinstall SecuRemote with the Update
option.
Modifying the Network Configuration

If you modify your computer’s network configuration after installing the SecuRemote
Client, you will have to re-install the SecuRemote Client.
Multiple adapters
If you have more than one adapter, the FW-1 adapter is bound to all of them. In
Windows 95, the binding is static and takes place when SecuRemote is installed. On
Windows NT, the binding takes place at boot time.
For example, in FIGURE 5-5, the Check Point Protocol (FW1) is bound to both the dial-
Up adapter and to the Intel EtherExpress adapter.
FIGURE 5-5 Network showing two FW-1 adapters

Removing the FW-1 adapter

If you are using both a dial-up and Ethernet connection, then in Windows 95, you may
find that you want to remove FW-1 adapter from the Ethernet adapter. There are two
ways to do this:
■ When installing SecuRemote, install it on only on the dial-up adapter.
Select this option during the installation process.

■ Remove the FW-1 adapter from the Ethernet adapter.
See “To remove the FW-1 adapters” below.
In Windows NT the need to remove the FW-1 adapter does not arise because the
binding is dynamic. When you remove the Ethernet adapter and re-boot, SecuRemote
binds only to the dial-up adapter.
To remove the FW-1 adapters

1 Open the Windows 95 Start menu and choose Control Panel.
2 Choose the Network applet.
3 In the Configuration tab of the Network window, select the FW-1 adapter you
wish to remove.
For example, in FIGURE 5-5, the FW-1 adapter (positioned between the Intel
EtherExpress PRO/10 adapter and the TCP/IP protocol) is selected.
If you have more than one adapter, make sure you select the one to which the
SecuRemote Client is attached.
4 Click on Remove.
5 Click on OK.
6 Reboot the computer.
Removing More than One Adapter

If you have more than one adapter, you can selectively remove SecuRemote from some
of them by removing the corresponding FW-1 adapters. In most cases, there is no need
to remove a FW-1 adapter.
If you wish to remove all the FW-1 adapters, uninstall the SecuRemote Client (see
“Uninstalling the SecuRemote Client” on page 108).
If you wish to remove more than one FW-1 adapter (but not all of them), then you
must select and remove each of the FW-1 adapters individually (see “Removing the
FW-1 adapter” on page 110), that is, you must click on OK to close the Network
window and reopen it for each deletion.

Defining Sites
Using the SecuRemote Client

Defining Sites
Before you can communicate using the SecuRemote daemon, you must define the sites
with which you wish to communicate.
The definition of a site depends on the SecuRemote Server.

■ When the SecuRemote Server is FireWall-1, a site is a Management Station that
manages one or more FireWall Modules.
In this case, the site itself is not necessarily a FireWall Module.

■ When the SecuRemote Server is VPN-1 Secure Center, a site is the SecuRemote
Server.
Once you define a site, you can use SecuRemote to communicate with any of the hosts
in the site’s encryption domain(s).
For example, in the enterprise network configured in FIGURE 1-1 on page 2, the
Management Station (Mango) in the Corporate Headquarters network manages all the
enterprise FireWalls.
installation diskette set.
If you click on the SecuRemote daemon’s icon (the icon in the taskbar’s system
tray) the Sites window is displayed. The first time you run the SecuRemote daemon,
no sites are defined (unless your system administrator has provided you with pre-
defined sites as part of your installation procedure).
FIGURE 5-6 Sites window

Adding a Site
▼ To add a new site
1 Make sure you are on-line to the network.
2 Open the Sites menu and select Make New Site or click on in the toolbar.
3 In the Site window (FIGURE 5-8 on page 113), type the resolvable name or IP
address of the site’s manager and click on OK.
If the site’s has more than one IP address or name, use the externally known
name. If this is not resolvable, try the other names one after the other until you
are successful.
The site will be queried for its RSA key and its encryption domain1 (its
topology). The SecuRemote daemon then stores this information locally on disk.
4 Authenticate yourself (see “Authentication Methods” on page 117) if you are

asked to do so.
5 If the query is successful, you will be reminded to verify that the information in
the Site window (FIGURE 5-7) is correct.
FIGURE 5-7 Verify Site reminder (Password and Certificate)
6 Verify the information by contacting the site’s system administrator by telephone

or other means.
For security reasons, you should not use the Internet to verify the information.
1.When the SecuRmote server is FireWall-1, the topology includes the encryption domains of all the FireWall
Modules managed by the site (Management Station).

Defining Sites
7 Click on OK.
FIGURE 5-8 Site window
After you add a site, it will appear in the Sites window. For example, FIGURE 5-9
shows a Sites window with two sites.
FIGURE 5-9 Sites window showing newly added sites

Viewing Sites
You can view sites either as icons (as in FIGURE 5-9 on page 113) or as a list
(FIGURE 5-10). To view the sites as a list, where the properties are displayed as well,
select Details from the View menu.
FIGURE 5-10 Site List
Deleting a Site
▼ To delete a site
1 Select the site by clicking on it.
2 Select Delete from the Sites menu or click on in the toolbar.
Properties
▼ To view a site’s properties
1 Select the site by clicking on it.
2 Select Properties from the Sites menu or click on in the toolbar.
Alternatively, you can double-click on the icon, or right-click on the icon to open
the Properties menu (see “Properties” on page 124).

Defining Sites
The Site window (FIGURE 5-11) is displayed.
FIGURE 5-11 Site window
You can update the site’s properties, that is, retrieve them from the site, by
pressing Update. You cannot directly modify any of the data in the window.

Authentication
The first time a SecuRemote Client initiates a connection to a site (and also whenever
a password expires), the user must first authenticate himself or herself to the
SecuRemote Server. The authentication method used depends on the encryption
method used for the connection.
FIGURE 5-12 SecuRemote Client User Authentication and Password windows
Encryption Method
The encryption method used depends on the encryption methods supported by the
SecuRemote Client and SecuRemote Server.
Versions 4.0 and higher of the SecuRemote Client support both FWZ and ISAKMP.
Earlier versions support FWZ only.
TABLE 5-2 lists the encryption methods supported by SecuRemote Servers.
TABLE 5-2 Encryption Method Supported
type of SecuRemote Server encryption methods supported

FireWall-1
■ Version 4.0 and higher — ISAKMP and FWZ
■ pre-Version 4.0 — FWZ only

VPN-1 Secure Center ISAKMP only

Authentication
TABLE 5-3 lists which encryption method is used for a given connection.
TABLE 5-3 Encryption Method Used
If the SecuRemote
Server supports ... then the method used is ...
FWZ and ISAKMP
■ SecuRemote Client Version 4.0 and higher — the method
specified under Default Key Scheme in the SecuRemote
Client’s Options window
■ SecuRemote Client pre-Version 4.0 — FWZ

FWZ only FWZ
ISAKMP only ISAKMP (SecuRemote Client Version 4.0 and higher)
Authentication Methods
There are several possible authentication methods:
FWZ
1 FWZ — any of the authentication schemes supported on the SecuRemote Server:
password, S/Key, RADIUS etc.
In the Password window, the user enters his or her user name and the password,
in accordance with the Authentication Scheme specified in the Authentication
tab of the User Properties window.
If the password is not entered, the user will be prompted for it.
If the encryption method is FWZ, the authentication is encrypted using Diffie-

Hellman keys.
ISAKMP
2 pre-shared secret (ISAKMP)
The SecuRemote Client and SecuRemote Server authenticate each other by

verifying that the other party knows the pre-shared secret, which is the user’s
password (as defined in the Authentication tab of the user’s ISAKMP Properties in
window). The user enters his or her user name in User and the pre-shared secret
in Password.

3 certificates (ISAKMP)
The user checks Use Certificate, enters an Entrust profile file name and a
Password to access the certificate.
The SecuRemote Client authenticates itself to the SecuRemote Server by using its
certificate. The SecuRemote Server verifies the certificate against a revocation
list. The SecuRemote Server authenticates itself by sending the SecuRemote
Client its certificate and a copy of a valid revocation list, signed by the
Password Window (FWZ Authentication)

The user must provide a password when initiating a communication with a host in the
site’s encryption domain. The password is used by the User Authentication feature. On
the user’s first attempt to connect to a site using FWZ encryption, the Password
window (FIGURE 5-13) will appear.
FIGURE 5-13 Password window
Enter a user name and a password. The SecuRemote daemon will remember them and
use them the next time it initiates a connection with the site.
Note – You may find that it is best to enter only a user name. The site will then request
the password in a separate step, and will indicate what kind of password to enter. In
this way, the user will not have to remember what kind of authentication scheme he
or she is using.
Once entered, passwords are stored in the SecuRemote daemon, and are not written to
disk (so they are “forgotten” when you re-boot). The SecuRemote daemon retains the
password in accordance with the parameters specified in the Options window
(FIGURE 5-16 on page 120).
Note – Passwords are verified by the site, not by the SecuRemote daemon. When you
change a password, the new password is verified only when it is first used.

Password Window (FWZ Authentication)
User Authentication
The User Authentication window is displayed on a user’s first attempt to connect to a
site, or whenever the password expires (see “Options window” on page 120).
FIGURE 5-14 SecuRemote Client User Authentication window
Site — the site’s name
This is a read-only field.
Use Certificate — If checked, then specify an Entrust profile file (.EPF file) or select
a hardware token (.TKN) from the drop-down list.
You can click on Browse to locate a profile.

You can view the profile by clicking on View. The Certificate window is
displayed.
FIGURE 5-15 Certificate window (User and CA tabs)
Note – You cannot modify the information in the Certificate window.
User — Enter the user’s name.
Password — Enter the password.
If Use Certificate is checked, then this is the password for accessing the profile.
Options
Options window
To display the Options window, select Options from the Passwords menu.
FIGURE 5-16 Options window

Options
To specify that passwords never expire (that is, that they are valid until the next time
the PC is turned off or re-booted), check Authentication is good for unlimited time.
Note – Even if this checkbox is checked, the FireWall-1 security administrator can (and
generally will) enforce a timeout on the password on the SecuRemote Server.
To specify that are valid for a fixed time period and must be re-entered at the end of
that period, check Authentication is good for limited time and enter that time.
To specify that passwords be echoed as they are typed, check Echo Password. If Echo
Password is not checked, asterisks are displayed as the user types a password.
When typing long passwords, it is useful for the user to be able to see what he
or she is typing. While it is true that security is enhanced when onlookers cannot
read a password from the screen as it being typed, this consideration is less
important for one-time passwords such as S/Key and SecurID.
Choose a Default Scheme from the menu. This is the encryption method that will be
used when the SecuRemote Server supports more than one method (see TABLE 5-2 on
page 116). You can choose either FWZ or ISAKMP.
Erasing Passwords
You can erase all the passwords (for all the defined sites) in the SecuRemote daemon
by selecting Erase Passwords from the Passwords menu. This forces the SecuRemote
daemon to “forget” the passwords. Open connections are not broken.
Alternatively, you can click on in the toolbar.
Passwords are also forgotten if you kill the Graphical User Interface (GUI) application
or re-boot the computer.
Password Expiration
The encryption key for SecuRemote remains valid for about 15 minutes. After this
time, another key exchange session between the SecuRemote Client and the site takes
place, and a new key may be calculated.
If the SecuRemote Client has “forgotten” its password, either because the user erased
it (see “Erasing Passwords” above) or because the timer set in the Options window
(FIGURE 5-16 on page 120) has expired, or if the authentication has timed out on the
gateway, the user will be re-authenticated.
This re-authentication will not take place (and instead the previous password will be
reused) if all the following conditions are true:
1 The password has not been erased.

Certificates
2 The Password Expires After timer in the user’s User Encryption Properties
window has not expired.
3 The Password Expires After timer on the gateway has not expired.
Entering a Password Before the Connection Begins

You can optionally enter a password even before you attempt a connection by selecting
a site and then choosing Set Password from the Passwords menu.
Alternatively, you can open the Properties menu (see “Properties” on page 124) by
right-clicking on a site’s icon or clicking on in the toolbar.
Certificates
If the encryption method specified in the Options window (FIGURE 5-16 on page 120) is
ISAKMP, you may be asked to supply a Certificate obtained from an Entrust Certificate
Authority in the User Authentication window (FIGURE 5-14 on page 119) when you are
asked to authenticate yourself.
Supplying an Entrust Certificate means specifying the location of an appropriate .EPF

file. SecuRemote defaults to the last .EPF file used, but you can specify another file
by clicking on Browse. For profiles on hardware tokens, the extension should be .TKN.
All available hardware profiles are shown in the User Authentication window, below
the Use Certificate checkbox.
ENTRUST.INI File
The file ENTRUST.INI, which contains information about the Entrust and LDAP
Servers, must be accessible to SecuRemote. Usually, this file is in the WINDOWS
directory, but you can specifiy an alternate location for it by selecting Select INI file
from the Entrust menu.
To configure an Entrust .INI file, choose Configure INI from the Entrust menu. The
Configure Entrust.INI window (FIGURE 5-17) is displayed.
FIGURE 5-17 Configure Entrust.INI window
CA Manager — Enter the IP address or resolvable name of the CA Manager and the
port number.

Entrust Users
LDAP Server — Enter the IP address or resolvable name of the LDAP Server and the
port number.
Entrust Users
Creating a Profile
To create an Entrust profile, choose Create User from the Entrust menu. The Create
User window (FIGURE 5-18) is displayed.
FIGURE 5-18 Create User window
Save Profile As — Specify the full path name of the file (for example,
c:\wildbill\wildbill.EPF), or the the hardware device (.TKN) on which the
profile will be saved.
User Password — Choose a password.
Verify Password — Enter the password a second time to ensure it is entered correctly.
Reference Number and Authorization Code — These values (generated by the

Certificate Authority) were given to you by your system administrator.
Recovering a User
If a user forgets his or her profile or a profile is corrupted, the system administrator
will arrange for the Certificate Authority to either create a new user or recover the
existing user.
■ If the Certificate Authority creates a new user, use the Create User window to
create a new user on the SecuRemote Client as well.
■ If the Certificate Authority recovers the existing user, use the Recover User
window to recover the user on the SecuRemote Client as well.

Properties
To recover an Entrust use, choose Recover User from the Entrust menu. The Recover
User window (FIGURE 5-19) is displayed.
FIGURE 5-19 Recover User window
Save Profile As — Specify the name of the file (.EPF) in which the profile will be
saved.
It is best to specify the name of the previous profile file, which will then be over-
written when you click on OK. You can use the Browse button to find the file.
User Password — Choose a password.
Verify Password — Enter the password a second time to ensure it is entered correctly.
Reference Number and Authorization Code — These values (generated by the

Certificate Authority) were given to you by your system administrator.
Properties
If you right-click on a site icon, the Properties menu is displayed.
FIGURE 5-20 Properties menu

Overview
The Properties menu items are shortcuts for menu commands (see TABLE 5-4).
TABLE 5-4 Properties menu items and their corresponding menu commands
Menu Item Menu Command

Delete Sites➤Delete
Properties Sites➤Properties
Set Password Passwords➤Set Password …
Closing the SecuRemote Daemon

To close the SecuRemote daemon window, select Exit from the File menu. The
SecuRemote daemon remains active, but its window is closed. To open it again, click
on its icon.
You can deactivate the SecuRemote daemon by selecting Kill from the File menu. The
SecuRemote kernel remains in the stack, but it does nothing. When you reboot the
computer or restart the SecuRemote Client from the Start menu, it becomes active
again.
You can also restart the SecuRemote daemon by selecting it from the FireWall-1 folder
in the Start menu.
Single SignOn
Overview
The Single SignOn option allows you to save your SecuRemote user name and
password so they do not have to be entered manually in the future. Single SignOn is
available for password authentication only, and is suitable for SecuRemote Clients with
only one site defined.
Configuring Single SignOn

1 Select Configure SSO from the Password menu.
FIGURE 5-21 Configure Single SignOn window

Single SignOn
2 In the Configure Single SignOn window (FIGURE 5-21), enter your NT and
SecuRemote user names and passwords.
3 To enable Single SignOn, select Enable SSO from the Password menu.
Your SecuRemote user name and password (your “credentials”) are then
encrypted in the Windows NT registry. The next time you restart your computer,
Single Signon will be in effect. On future boots you will not be prompted for this
information.
FIGURE 5-22 Single SignOn Enabled window
Disabling Single SignOn

To disable Single Signon, select Disable SSO from the Password menu.
FIGURE 5-23 Disabling Single SignOn window

File Menu
SecuRemote Client Menus

File Menu
TABLE 5-5 File Menu Commands
Menu Toolbar
Entry Button Description See
Exit
Kill
View Menu
TABLE 5-6 View Menu Commands
Menu Toolbar
Toolbar none Toggle the display of the “SecuRemote Client Toolbar” on
SecuRemote Client toolbar. page 130
Status Bar none Toggle the display of the
SecuRemote Client Status
Bar.
Large Icons Display sites as large icons. “Viewing Sites” on page 114
Small Icons Display sites as small icons. “Viewing Sites” on page 114
List Display sites as a list. “Viewing Sites” on page 114
Details Display sites as a list “Viewing Sites” on page 114
showing details.
The SecuRemote Client toolbar is displayed below the menu. The SecuRemote Client
Status Bar is displayed at the bottom of the FireWall-1 window.

SecuRemote Client Menus
Sites Menu
TABLE 5-7 Sites Menu Commands
Menu Toolbar
Make New Make a new site. “Adding a Site” on page 112
Delete Delete a site. “Deleting a Site” on page 114
Properties Display a site’s properties. “Properties” on page 114
Password Menu
TABLE 5-8 Password Menu Commands
Menu Toolbar
Set Enter a new password to be “Entering a Password Before the
Password used for the next Connection Begins” on page 122
authentication.
Erase Erase all the password’s “Erasing Passwords” on page 121
Passwords from the SecuRemote
daemon’s memory
Configure Configure your SecuRemote “Single SignOn” on page 125
SSO credentials.
Enable SSO Enable the Single SignOn “Single SignOn” on page 125
option.
Disable SSO Disable the Single SignOn “Single SignOn” on page 125
option.
Tools Menu
TABLE 5-9 Tools Menu Commands
Menu Toolbar
Options Display the Options “Options window” on page 120
window.

Entrust Menu
Entrust Menu
TABLE 5-10 Entrust Menu Commands
Menu Toolbar
Create User “Creating a Profile” on page 123
Recover Recover a user on the “Recovering a User” on page 123
User Certificate Authority
Select INI Specify an INI file to be
File used.
Configure
INI File
Help Menu
TABLE 5-11 Help Menu Commands
Menu Toolbar
Index none Display Help.
Using Help none Display instructions for
using Help.
About none Display the “About
SecuRemote SecuRemote” window.

SecuRemote Client Toolbar
SecuRemote Client Toolbar
FIGURE 5-24 SecuRemote Client Toolbar
The toolbar buttons are shortcuts for menu commands (see TABLE 5-12).
TABLE 5-12 Toolbar buttons and their corresponding menu commands
Toolbar Button Menu Command
Sites➤Make New
Sites➤Delete
Sites➤Properties
Passwords➤Set Password
Passwords➤Erase Passwords

CHAPTER 6
Troubleshooting
In This Chapter
General Troubleshooting Procedures page 131

Encryption Error Messages page 133
Troubleshooting SecuRemote page 142
General Troubleshooting Procedures

Preventing Common Problems
IPSec and ISAKMP
It is crucial that the computer’s host name correspond to the IP address of its external
interface’s IP address. If this is not so, IPSec packets will carry the internal interface’s
non-routable IP address, and reply packets will not be routed back to the computer.
You can find out the IP address that corresponds to the hostname as follows:
Unix
The IP address is given in the response to the hostname command.
NT
1 From the Control Panel, double-click on Network.
2 In the Network window, click on the Protocols tab.
3 Select TCP/IP and click on Properties.
4 In the Microsoft TCP/IP Properties window, click on DNS.

The computer’s name is in Host Name.
131
General Troubleshooting Procedures
5 From a command window, ping the name in Host Name.

The response to the ping command should show a resolvable legal IP address.
SKIP
SKIP requires that clocks be synchronized to a difference of no more than 1 hour.
Examining the Log

Whenever there is a problem in the encryption protocol, the result is that the
connection will either hang, or be dropped or rejected by one of the gateways.
The first step in troubleshooting should be to examine the log. Of course, the log will
show information about the connection only if logging is specified for the encryption
rule in the Rule Base.
If an encrypted connection is successfully established, the log shows an Encrypt entry

for Alice and a Decrypt entry for Bob.
If the encryption protocol fails, then the log shows a Reject action for Alice. The Info
field then has an error message of the form:
Encryption Failure : <error diagnostic>
In addition, the encryption scheme and the methods are given.
There is usually also a similar entry for Bob, with the Info field showing an error
message of the form:
Decryption Failure : <error diagnostic>

Configuration
Configuration
In the examples that follow, the encryption is of a TELNET session between the hosts
Arthur and Betty, configured as shown in FIGURE 6-1.
FIGURE 6-1 Network Configuration for Troubleshooting Examples
Encryption Error Messages

Basic Encryption Protocol
Errors Reported by Alice (Encrypting Gateway)
The messages in this group are reported by Alice (the encrypting gateway), and the
problems and their solution are to be found in Alice’s database.
The solution usually consists of correcting a configuration error on Alice’s Management

Station (Andy in this example) and downloading the corrected Security Policy to Alice.
It is sometimes sufficient to download just the database.
TABLE 6-1 Errors Reported by Alice (Encrypting Gateway)
Scheme Error Message Meaning Course of Action

All There is no encryption Alice did not try to encrypt the Check the rule number in the
error message, but there connection. log and determine which rule
is some other log entry was applied instead of the
for the connection. encryption rule, and why.
All “Neither source nor A rule specifies encryption, but Correct the Rule Base and/or
destination is in my the gateway is responsible for the gateway’s Encryption
domain” neither source nor destination. Domain.
All “I (Alice) don’t have a Alice is not defined in the Correct Alice’s database
network object” database.
Chapter 6 Troubleshooting 133

TABLE 6-1 Errors Reported by Alice (Encrypting Gateway) (continued)

All “Rule peer gateway The gateway defined in the rule Correct Alice’s database.
gateway name does not as Peer Gateway does not
match destination” include the destination in its
Encryption Domain.
All “No peer gateway found Alice did not identify Bob as Correct Alice’s database.
for the destination” the gateway responsible for the
connection to Betty. In other
words, in Alice’s database,
Bob’s Encryption Domain is
incorrectly defined.
All “unknown scheme” FireWall-1 version does not Contact your FireWall-1
support this scheme. support representative.
ISAKMP “Peer does not support Bob does not support ISAKMP. Correct Bob’s configuration.
ISAKMP”
ISAKMP “I don’t support Alice does not support Correct Alice’s configuration.
ISAKMP” ISAKMP.
ISAKMP “No matching There are no encryption or Correct Alice’s and/or Bob’s
encryption/hash methods hash methods supported by configuration.
between myself and both Alice and Bob.
peer”
ISAKMP “Certificate’s Subject ID The Subject ID in Bob’s Confirm that the match
does not match peer’s ID certificate is different from certificate criteria (in the
id” Bob’s ID. Public Key Configuration
id is the subject ID in Bob’s window) are correct. If they
certificate. are, the certificate may be
forged.
ISAKMP “Peer’s certificate Bob’s certificate is invalid. Bob must obtain a valid
invalid: text” text is the reason that the certificate. The certificate Bob
certificate is invalid. presented may have been
tampered with or used by an
eavesdropper.
ISAKMP “No response from peer: Bob did not respond to Alice’s Confirm that fwd and
scheme ISAKMP” ISAKMP negotiation messages. isakmpd are running on Bob
(both are started by
fwstart).
ISAKMP “ISAKMP daemon: no The ISAKMP daemon Obtain and install a valid
‘encryption’, ‘des’, or (iskampd) cannot execute license.
‘isakmp’ license” because of a license problem.
ISAKMP “Cannot read the The relevant rule’s Rule Define the rule’s Rule
methods from the rule” Encryption Properties have not Encryption Properties and set
been defined. the methods.


ISAKMP “Cannot communicate The FireWall daemon (fwd) is The ISAKMP daemon may not
with the ISAKMP unable to communicate with be running, or there may be
daemon” the ISAKMP daemon another process listening on
(isakmpd). UDP port 500. Run fwstop,
kill the other process, and
run fwstart.
ISAKMP “Error: ISAKMP signing FireWall-1 did not find the RSA Generate a signing key for
key cannot be found” signing key in its database. Alice in the ISAKMP Public
Key Configuration window.
ISAKMP “Error: ISAKMP FireWall-1 did not find the Obtain a certificate for Alice
certificate cannot be ISAKMP signing key certificate in the ISAKMP Public Key
found” in its database. Configuration window.
ISAKMP “Error: ISAKMP CA’s FireWall-1 did not find the Generate a signing key for
certificate cannot be ISAKMP signing key certificate Alice in the ISAKMP Public
found” in its database. Key Configuration window.
ISAKMP “Error: ISAKMP The certificate in the database Generate a new certificate for
certificate not valid: is invalid. Future ISAKMP Bob in the Public Key
text” negotiations using signature Configuration window.
authentication mode will fail.
text specifies the reason.
ISAKMP “Warning: ISAKMP Failed to check the validity of Confirm that the cms daemon
certificate not valid: Bob’s certificate in the and your PKI are running.
text” database. Future ISAKMP Confirm that FireWall-1 can
negotiations using signature communicate with the PKI.
authentication mode may use
the certificate. text specifies the
reason.
FWZ, SKIP “Peer (Bob) has neither There is no key information for Correct Alice’s database.
CA nor key” Bob defined in Alice’s Obtain a key for Bob.
database.
FWZ, SKIP “I (Alice) have no private Alice has no private key Generate a key for Alice.
key” defined.
FWZ “Peer (Bob) failed to Bob did not reply to Alice’s There are several possible
reply” encryption request. causes for this failure:
■ Check if FireWall-1 is
running on Bob.
■ Check Bob’s log for

errors. If Bob is managed
by a remote organization,
this step may require
coordination with Bob’s
system administrator.


FWZ “Illegal peer reply” or This should never happen. The Bob’s reply may have been
“Peer (Bob) failed to message indicates that Bob’s tampered with.
authenticate its reply” reply is not in the correct
format, or that its
cryptographic signature is
incorrect.
FWZ “Failed to generate Internal FireWall-1 error. Contact your FireWall-1
shared key” or “Session support representative.
key installation failed”
FWZ “CA name has no CA Correct the database.
key.”
ISAKMP, SKIP, “No encryption license” You are attempting to use Obtain and install a valid
Manual IPSec encryption without a license license.
ISAKMP, SKIP, “No scheme license” You are attempting to use an Obtain and install a valid
Manual IPSec encryption scheme for which license.
you have no license.
SKIP “Failed to compute a A key for one of the sides is Check that both keys are
shared secret” either missing or has expired. defined and valid.
Manual IPSec “Source/Destination is One of the sides is not defined Check Manual IPSec in the
not a manual key as a manager of manual keys. Key Management window in
manager” the OpenLook GUI
(FIGURE 3-13 on page 51) or
in the Encryption tab of the
Workstation Properties
window in the Windows GUI
(FIGURE 3-1 on page 37).
Errors Reported by Bob (Decrypting Gateway)

The messages in this group are reported by Bob (the decrypting gateway), and the
problems and their solution are to be found in Bob’s database.

The solution usually consists of correcting a configuration error on Bob’s Management

Station (Barbara in this example) and downloading the corrected Security Policy to
Bob. It is sometimes sufficient to download just the database.
TABLE 6-2 Errors Reported by Bob (Decrypting Gateway)

ISAKMP, SKIP, “No encryption license” You are attempting to use Obtain and install a valid
Manual IPSec encryption without a license license.
ISAKMP, SKIP, “No scheme license” You are attempting to use an Obtain and install a valid
Manual IPSec encryption scheme for which license.
you have no license.
ISAKMP “Peer uses wrong methods” Alice has sent an encrypted Correct Alice’s
packet with the wrong configuration.
ISAKMP methods.
SKIP “Failed to compute a shared A key for one of the sides is Check that both keys are
secret” either missing or has defined and valid.
expired.
Manual IPSec “Source/Destination is not a One of the sides is not Check Manual IPSec in the
manual key manager” defined as a manager of Key Management window
manual keys. in the OpenLook GUI
(FIGURE 3-13 on page 51)
or in the Encryption tab of
the Workstation
Properties window in the
Windows GUI (FIGURE 3-1
on page 37).
SKIP “Rule NSID differs from There is a mismatch in NSID Correct the Rule Base so
packet NSID” types. that the NSID matches on
both sides of the
connection.
SKIP “Mismatch between rule and There is a mismatch in Correct the Rule Base so
packet Kij/Crypt/Auth methods. that the methods match on
methods”. both sides of the
connection.
SKIP “Source/Destination object A SKIP packet has been If required, define the
not in database” received from an unknown unknown SKIP gateway in
SKIP gateway. the database.
SKIP “Cannot find Source/ Cannot locate the SKIP DH Define the key.
Destination key hash in key.
database”
SKIP “Packet Source KeyID (keyid) The peer is using a SKIP key Update the peer’s SKIP
does not match database different from the one in the key.
KeyID” database.
SKIP “Packet Destination KeyID Peer does not have Bob’s Inform peer of Bob’s
(keyid) does not match correct key. correct key.
database KeyID”

TABLE 6-2 Errors Reported by Bob (Decrypting Gateway) (continued)

SKIP “NSID 1 source address The NSID 1 KeyID (IP Inform the peer.
mismatch” address) does not match the
peer’s IP address.
SKIP “NSID 1 destination address The peer is using an Inform the peer.
is not mine” incorrect IP address for the
NSID 1 key.
Manual IPSec “Couldn’t get SPI data” Bob received a packet with Define the SPI that the
an unknown SPI. peer is using.
FWZ “Matching rule is not FWZ” The rule that matches the Correct the database.
RDP request specifies a non-
FWZ encryption scheme.
FWZ “Mismatching/Illegal The RDP request asks for an Correct the Rule Base.
encryption method” unsupported encryption
scheme, or does not match
the methods in the relevant
rule.
FWZ “Matching rule does not The relevant (matching) rule Correct the Rule Base.
encrypt” does not allow encryption.
FWZ There are no log entries. Bob thinks that Betty is not Correct Bob’s database.
in Bob’s Encryption
Domain, and ignored Alice’s
RDP request packet,
assuming that there is
another gateway behind Bob
that will handle the request.
FWZ “No matching decryption rule here is no encryption rule on Correct Bob’s Rule Base.
found” Bob that corresponds to
Alice’s encryption connection
request.
FWZ “Illegal peer request” This should never happen. It may be that Alice’s
The message indicates that encryption connection
Alice’s encryption connection request has been tampered
request is not in the correct with.
format.
FWZ “Illegal encryption method” Alice has requested an Agree on the encryption
encryption method that Bob methods to be used for the
does not support for this connection, and define the
connection. methods in the Encryption
Properties window of the
relevant rule in the Rule
Bases of both Alice and
Bob.

TABLE 6-2 Errors Reported by Bob (Decrypting Gateway) (continued)

FWZ “Cannot find peer’s (Alice’s IP Alice is not defined in Bob’s Define Alice (including its
address) object” database. key and Encryption
Domain) in Bob’s
database.
FWZ “Peer (Alice) is not In Bob’s database, Alice’s Correct Bob’s database.
responsible for src” Encryption Domain does not
include Arthur (the source of
the connection).
FWZ “Peer did not send my key” Bob is not included among Correct Alice’s database
Alice’s suggestions for an (from Alice’s Management
encrypting gateway. Station).
There are several possible
causes for this failure:
Alice’s database has the
wrong IP address for Bob, or,
in Alice’s database, Betty is
not in Bob’s Encryption
Domain, but in the
Encryption Domain of some
other gateway.
FWZ “Peer (Alice) has neither CA In Bob’s database, there is Correct Bob’s database by
nor key” no public key for Alice. fetching a key for Alice.
FWZ “Peer claims to have more Alice has a more up-to-date Download Bob from
updated version of my key” version of Bob’s key than Barbara.
Bob has. This can happen if
Alice got Bob’s key from
Barbara (Bob’s Management
Station) but Bob has not yet
gotten the key from Barbara.
FWZ “Peer (Alice) claims to have This is the reverse of the Download Alice from
older version of its key” previous problem. This can Andy.
happen if Alice has not yet
fetched its own key from
Andy (Alice’s Management
Station) but Bob has fetched
Alice’s key from Andy.
FWZ “Failed to generate shared Internal FireWall-1 error. Contact your FireWall-1
key” or “Session key support representative.
installation failed”

Extended Encryption Protocol (FWZ only)

The errors in this section can occur when a gateway asks a peer for its certified key
(signed by the CA).
TABLE 6-3 Extended Encryption Protocol — Key Update Protocol Errors

FWZ “Barbara (Bob’s CA) has no Alice’s database does not have Fetch Barbara’s CA key
CA key” Barbara’s CA key, and will not to Alice’s database, using
accept Bob’s key. the Certificate Authority
Key window, and then
verify the key out-of-
band.
FWZ “Barbara (Bob’s CA) has Alice’s database has a different Fetch Barbara’s CA key
probably changed its key” CA key for Barbara, and will to Alice’s database, using
not accept Bob’s key. the Certificate Authority
Key window.
FWZ “Peer has not got my correct Alice’s received a request from On Barbara (Bob’s
CA key” Bob for Alice’s key, but Bob Management Station),
does not have the correct CA fetch Andy’s CA key to
key for Andy (Alice’s CA). Bob’s database, using the
Certificate Authority
Key window.
FWZ “Bad signature of CA Barbara’s signature is incorrect. It may be that the
Barbara for Bob’s key” protocol packet has been
tampered with.
FWZ “Peer failed to reply to key Alice did not receive a reply to Check Bob’s log for
request” its request (to Bob) for Bob’s relevant error messages.
encryption key. This can
happen if Alice has a bad CA
key for Barbara (Bob’s CA).
The same error messages can appear in Bob’s log, with the roles reversed.
Fetching Keys from a Remote Certificate Authority

When you click on Get or Apply in the Key Management window of a remotely
managed gateway, FireWall-1 attempts to fetch the gateway’s public key from its
Certificate Authority. If this attempt fails, an error message is displayed in a pop-up
window. Following is a list of these error messages and explanations of what they
mean, as well as suggestions for solving the problems they indicate.
The problem can often be solved by downloading the corrected Security Policy. It is
sometimes sufficient to download just the database.

In the examples that follow, the remote gateway’s name is Floyd and the CA’s name is
Oscar.
TABLE 6-4 Fetching Keys from a Remote Certificate Authority Errors

“Communication with Floyd’s These messages indicate that the Confirm that you have the correct
Certificate Authority (Oscar) local computer is unable to IP address for the remote CA.
failed” or “Cannot connect to communicate with the remote CA Ping the CA to confirm that you
Certificate Authority (Oscar)” (Oscar). are able to communicate with it.
Contact the CA’s system
administrator to confirm that the
FireWall-1 daemon on the CA is
indeed running, and that it has
no configuration problems.
“Oscar says that it is not a Though Oscar is FireWalled and the Contact the CA’s system
Certificate Authority” FireWall-1 daemon is running, there administrator to confirm that
is no CA key defined for it. there are no configuration
problems.
“Certificate Authority (Oscar) This message usually indicates that In the CA’s Certificate Authority
claims to have a different the Certificate Authority has Key window, re-fetch the key by
certificate public key” changed its RSA certificate public clicking on Get.
key since the last time it was
fetched by the local computer. This
can happen only after the key was
fetched once.
“Certificate Authority (Oscar) This message indicates that the Confirm that you have the correct
denies knowledge of Floyd” gateway is not controlled by the CA IP address for the gateway.
(which is always a FireWalled Contact the CA’s system
machine). administrator and verify that the
gateway is one for which the CA
is responsible.
“Certificate Authority (Oscar) This message is similar to the Contact the CA’s system
does not have key defined for previous one, and indicates that the administrator and verify that the
Floyd” gateway is defined in the CA’s gateway is one for which the CA
FireWall-1 database, but not as a is responsible.
gateway that performs encryption.

Troubleshooting SecuRemote
TABLE 6-4 Fetching Keys from a Remote Certificate Authority Errors (continued)

“WARNING: Getting Oscar’s This message does not indicate an As a precaution against
management key WITHOUT error, but is a warning which is tampering, it is recommended
AUTHENTICATION. Verify the issued the first time a computer that you contact the CA’s system
transaction MANUALLY” fetches a CA’s public key without administrator by some non-
authentication. network means (such as telephone
or fax) and verify that you
received the CA’s public key
correctly.
The key can be verified by the
KeyID field (a 24 hex character
MD5 cryptographic hash of the
actual key value) displayed in the
Certificate Authority Key
window.
“Certificate Authority’s (Oscar) This message indicates that the
signature for Floyd is bad” RSA signature the CA sent for the
key for the gateway has been
tampered with. This should never
happen under normal
circumstances.
“Certificate Authority’s (Oscar) This message indicates that the key If you wish to use the outdated
response for Floyd is outdated” the CA sent for the gateway is key, delete the current key by
outdated, that is, its generation unchecking FWZ in the gateway’s
date precedes the generation date Key Management window and
in hand for the gateway’s key. It is pressing Apply. Next, open the
likely that the system administrator window again and re-fetch the
at the CA reverted to an old key key.
database.
Installation
You may receive the following message when you install the SecuRemote Client:
Setup program has found that a previous installation was removed

without rebooting the computer. Please reboot your computer
before re-installation.
This usually means that you uninstalled SecuRemote and then re-installed it before
first rebooting you machine. Reboot and try again to re-install. If the problem persists,
then delete the file sruninst.exe from your Windows directory and re-install.

Routing
It may happen that your first attempt to use the SecuRemote Client will expose
preexisting routing problems of which your system administrator was previously
unaware if this is the first time someone is accessing the server from outside the local
network. In this event, you can trace the routing by using tracert from the PC. Your
system administrator can provide you with instructions on how to use tracert.
No SecuRemote Server Along Route

If there is no SecuRemote Server along the route between the PC and the host with
which it is communicating, then communication is not possible (there is no one to
decrypt what SecuRemote is encrypting). This can happen, for example, when a
portable computer is moved from home to office and the computer’s IP address at the
office is not in the same Encryption Domain as the destination. (If it is in the same
Encryption Domain, then no encryption will take place.)
In this case, the only solution is to disable SecuRemote (and thus communicate
without encryption), either by killing the SecuRemote Client or by removing the
FireWall-1 adapter from the interface. For example, if the FireWall-1 adapter is
installed on the dial-up interface but not on the Ethernet interface, then SecuRemote
will encrypt when the user is working at home but not encrypt when the user is
working at the office. See also “Data Not Encrypted” on page 93.
Password Dialog Box

If something goes wrong, you will need to determine whether the problem is on the
SecuRemote Client side (on the PC) or on the SecuRemote Server side. In general, if
the SecuRemote Client displays the password dialog box, then it is functioning
correctly and whatever problems you are experiencing are on the SecuRemote Server
side of the connection.
If you don't see the password dialog box, then one of the following is probably true:
■ The SecuRemote software was not correctly installed on the PC.
■ The site with which you are trying to communicate was not defined on the PC.
■ The information received from the Management Station when the site was
defined is incorrect.
This can happen if the site information on the PC is old and it should be
updated, or if the SecuRemote Server’s encryption domain is not properly
defined.
You can verify the information on the PC by browsing through the file userc.c in the
database directory under the directory on which you installed SecuRemote.The
default path is
C:\Program Files\CheckPoint\SecuRemote\database\userc.c.

In this file there should be several fields of the form:
(
gws(
:topology (
: (
....
:ipaddr ( xxx.xxx.xxx.xxx)
:ipmask ( yyy.yyy.yyy.yyy)
...
)
...
)
One of these ipaddr-ipmask pairs should match your destination. If none does, then
proceed as follows:
1 Exit any editor that you may have opened on userc.c.
2 Update the site with which you want to encrypt.
3 Check the userc.c file again.
If the problem has not been solved, contact your system administrator for assistance.
You can make a backup copy of userc.c when experimenting, but there is no point in
manually editing it since SecuRemote updates it automatically.
Service Cannot be Accessed

If you cannot access a service, disable SecuRemote (choose Kill from the File menu)
and try again.
If you cannot access the service even when not using SecuRemote — It is
the Security Policy that is denying you access, and you should contact your
system administrator for assistance.
If you can access the service when not using SecuRemote — There is a
problem with the way SecuRemote is configured on your PC.

Data Not Encrypted

If data is being transmitted in the clear (that is, data is not being encrypted) and no
authentication is taking place (that is, you don’t see the User Authentication or
Password windows), then examine the following possibilities:
■ SecuRemote is not properly installed (Windows 95)
Course of Action — Open the Network dialog box and verify that
FW1 Adapter/Protocol is between the TCP/IP and the adapter through
which you expect the data to pass. For example, if you have both Dial-up
and Ethernet adapters, and FW1 is bound to the Dial-up adapter, then
unplug the Ethernet cable from the wall.
Make sure that the SecuRemote Daemon is running after the PC completes its
boot.
■ The SecuRemote Client on the PC does not know that it must encrypt the data
Course of Action — Encryption takes place only if the destination is in the

FireWall’s encryption domain (which must be exportable to the PC using the
Update or Make New Site operations), and the source is not in the
FireWall’s encryption domain.
■ The information received by the SecuRemote about which IP address should be
used with encryption may be incorrect.
You can verify this information by examining the file userc.c in the database
directory under the directory on which you installed SecuRemote. The default
path is given in TABLE 6-5.
TABLE 6-5 Default path for userc.c
OS default path for userc.c

Windows 95 C:\Program Files\CheckPoint\SecuRemote\database\userc.c
Windows NT WINDIR\fw\database\userc.c
This file contains a set whose first entry should be of the form:
(
gws (
.....
)
....
)
Make sure that the IP Address with which you want to encrypt is within the
topology attribute of the gws set (one of these ipaddr-ipmask pairs should
match your destination). If this is not so, for example if the gws set is empty
(that is, gws ()), then proceed as follows:

1 Exit any editor that you may have opened on userc.c.
2 Update the site.
3 Check the userc.c file again.

■ The FireWall instructed the SecuRemote to send the data in clear
Course of Action — In the Log Viewer, you should see an entry with an
envelope in which the user name and the key-id appear.
If this is not the case, then the SecuRemote user was defined to work in the
clear.
Open the user's User Properties window and click on Encryption. Verify that the
data encryption method is correct. If this is not the problem, proceed to the next
item in this procedure.
Open the Workstation Properties window of the FireWall that should be doing the
decryption.
Verify that:
■ Encryption Domain is valid
■ Exportable is checked
In the SecuRemote user’s User Properties window, verify that:

■ The user’s name is identical to the user name as specified in the Password
window on the SecuRemote Client.
■ Data Encryption Method is not set to Clear.

Master Index
SYMBOLS limiting to specific ports, AA-355

#define restoring, to blocked system, AA-336
difference between #define and define, AA-302, Access Control
AA-311 logging, AA-225
$FWDIR/conf/smtp.conf Access Lists
description, AA-111 managing imported access lists, OL-140
$FWDIR/conf/xlate.conf Properties, WI-148, OL-115
explanation of fwx_translation table, AA-215 router, installing, WI-200, OL-142
$FWDIR/log/fw.log, AA-265 router, uninstalling, OL-142
.EPF files, VP-122 Wellfleet, AA-280
Account Management, AA-135, WI-94
NUMERICS defining users in both LDAP and
3Com routers FireWall-1, AA-142, AA-154
managing in the rule base, WI-47, OL-46 Account Management Client, WI-74
setup, WI-42 installation error message, AM-10
installing, AM-8
A JRE installation, AM-13
abandon parameter location on CD-ROM, AM-8
smtp.conf, AA-111 minimum requirements, AM-7
Accept Domain Name Download, OL-111, OL-115 operating systems, AM-7
Accept Domain Name Queries , OL-111, OL-115 platforms, AM-7
Accept ICMP, WI-145, OL-111, OL-116 uninstalling, AM-13
Accept Outgoing Packets, OL-110 Account Management for Enterprise Console, GS-81
Accept Outgoing Packets property, WI-178 Account Unit
Accept RIP, OL-110, OL-115 defined differently in AM Client and
Accept UDP Replies, OL-110 FireWall-1, AM-55
access description of, AM-4
LEGEND
AA Architecture and Administration AM Account Management Client GS Getting Started with FireWall-1
OL Managing FireWall-1 Using the OpenLook GUI VP Virtual Private Networking with WI Managing FireWall-1 Using the Windows GUI
FireWall-1
managing users on, WI-75 interaction with anti-Spoofing, AA-205
properties, AM-17 internal host with illegal IP address tries to
step by step instructions on how to use in Security communicate with external host with same IP
Policy, AA-140 address, AA-214
Account Unit Properties window multiple translation, AA-176
Encryption tab, AM-18 need for, AA-155
General tab, AM-17 PIX, AA-199
accounting, AA-240, WI-214, OL-153 reply packets, AA-166
and synchronized FireWalls, AA-234 restrictions on rshell service, AA-171
incompatible with FASTPATH, AA-325 restrictions on sqlnet2 service, AA-171
ACE restrictions on Xing service, AA-171
configuring FireWall-1 to work with ACE routing considerations, AA-165
software, AA-356 Rule Base, AA-210
sdconf.rec file, AA-357 Static Destination mode, AA-164
using DES option with FireWall-1, AA-365 Static Source mode, AA-162
Action Selection window, WI-231 translation both source and destination, AA-176
active connections, AA-240, WI-215, OL-154 using with Encryption on the same system, AA-213
ActiveX, WI-123, OL-87 Address Translation configuration utility, AA-283
Additional Information Selection dialog box, OL-163 Address Translation Rules
Additional Information Selection window, WI-233 generating automatically, AA-171
additional reading, GS-26 Address Translation tab, WI-158
add-on products, GS-81 Network Properties window, WI-33
address range , WI-61 Workstation Properties window, WI-30
defining, AA-177 administrators
Address Translation adding or deleting, AA-225
and auxiliary connections, AA-321 AIX, see IBM AIX
and FTP PASV, AA-321 alert command
and SecuRemote, VP-91 anti spoof, WI-147
communications between hosts in different internal anti-spoof, WI-147, OL-114
networks, AA-196, AA-198 mail, WI-147, OL-113
compound conditions, AA-176 popup, WI-147, OL-113
configuring, AA-189 SNMP, WI-147
differences between the Command Line Interface and SNMP Trap, WI-147, OL-113
the GUI, AA-190 User Authentication, WI-147, OL-114
different configurations on different network user authentication, WI-147
objects, AA-216 user defined, WI-147, OL-113
explanation of fwx_translation table, AA-215 alert.exe file, AA-376
FTP port command, AA-171 alerts
gateway with three interfaces, AA-194 received by, WI-207
gateway with two interfaces, AA-191 sent to, WI-207
Hide mode, AA-158, AA-159 alias, AM-61
hiding the gateway’s internal address, AA-211, aliased interfaces, AA-363
AA-215 America OnLine, AA-387
installing on selected hosts, AA-189 Anti Spoof Alert Command, WI-147
LEGEND
FireWall-1
Index-ii FireWall-1 User Guide Master Index • September 1998

anti-spoof Alert Command, WI-147, OL-114 backup
anti-spoofing, GS-99, WI-25, WI-48, OL-35, OL-47 backing up a Security Policy, AA-344
compatibility with Address Translation, AA-205 backward compatibilty
example, WI-26 Version 4.0 and earlier versions, GS-34
interaction with Address Translation, AA-205 BackWeb, AA-322, AA-393
AOL, AA-387 base.def file, AA-380
application Basic Encryption Protocol, VP-133
silently dropping, WI-173, OL-132 Basic Session Key, VP-24
Apply Gateway Rules to Interface Direction Bay Networks router, GS-8, GS-74, GS-77, GS-97,
property, AA-368 WI-170, WI-197, OL-39, OL-139
Apply Selection, WI-237, OL-165 defining network object as, WI-22, WI-41, OL-33
Archie, OL-68 installing Encryption Module on, GS-77
archie, AA-393 installing FireWall-1 on, WI-36, OL-39
ARP, AA-233 setup, WI-41, OL-41
aSERVERNAME.log file, AA-383 before installing FireWall-1, GS-31
auth.C file, AA-377 bibliograpy, GS-26
auth.def file, AA-380 Big Endian, AA-315
authenticated services Blackbox Properties , WI-48, WI-53
going across two or more FireWalls, AA-359 Block Intruder window, WI-216
authentication Block Request window, WI-217
and synchronized FireWalls, AA-233 blocked system, restoring access to, AA-336
authentication methods, AA-28 blocking connections, AA-269
authentication schemes, AA-30 boot process
comparison of different types, AA-29 protecting networks during, AA-319
re-authenticating an FWZ SecuRemote protecting the gateway during, AA-320
connection, AA-151 bootp, AA-394
transparent authentication, AA-28 broadcast packets
when to use each type, AA-29 prevent them from being identified as spoofed
Authentication methods, AA-28 packets, OL-37
Authentication Passwords
synchronizing, AA-351 C
authkeys.C file, AA-379 cannot connect to the server
authrules.C file, AA-379 error message, AA-340
Auto Scoping, WI-38, OL-39 CD-ROM
auxiliary connections, AA-321 location of files on, AM-8
AXENT Pathways Defender, AA-30, AA-51, AM-48 certificate, AA-151
defining as server, WI-101 Certificate Authority, WI-106, VP-5
AXENT Pathways SecureNet, AA-365 changing its public key, VP-71
ENTRUST, VP-46
B function of, VP-5
back connection Certificate Authority Keys window, VP-70
requested port, AA-321 Certificate Discovery Protocol, VP-9
back connections, AA-325, WI-85, OL-67 Certifying a Public Key, VP-5
encrypting, VP-71 chargen, AA-387, AA-394
LEGEND
FireWall-1
Master Index Index-iii

Check Point color, AA-178, AA-179, WI-84, WI-87, WI-88,
home page, GS-29 WI-91
checksum errors, WI-148, OL-114, VP-39 Column menu, WI-219
chkpnt.mib file, AA-382 Column Selection menu, WI-225
Cisco, GS-8 comment, AA-178, AA-179, WI-84, WI-86, WI-87,
fwciscoload, AA-273 WI-88, WI-91, OL-72, OL-73
setup, OL-40 adding to a rule, WI-172
Cisco PIX firewall communication
setup, WI-56, WI-57 between FireWall-1 components on different
Cisco router machines, AA-345
defining network object as, OL-33 compartmentalization
setup, WI-40 Account Units, AM-5
Client Authentication compatibility
authorizing services, AA-77, AA-82 Version 4.0 and earlier versions, GS-34
configuring, AA-78 compiler, FireWall-1, AA-279
configuring support for HTTPS, AA-94 compiling a Security Policy, AA-257
defining on a per-user rather than a per-group conf/masters, AA-327, AA-341, AA-347
basis, AA-357 configuration
logging, example of, AA-87 Security Servers, AA-123
overview, AA-75 configurations
sign on methods, AA-76 managing distributed FireWall-1
signing on through a Web browser, AA-91 configurations, AA-345
Single Sign On System Extension, AA-98 Conn. ID, WI-215, WI-217, OL-154, OL-155
timeouts, AA-84 Connected OnLine Backup, AA-387
tracking, AA-83 connection to original-MTA failed
Client Authentication Sign On Methods error message, AA-361
fully automatic sign on, AA-77 connections
manual sign on, AA-76 blocking, WI-215
manual sign on through a Web browser, AA-91 different routes for, AA-230
manual sign on using TELNET, AA-87 inhibiting or blocking, AA-269
partially automatic sign on, AA-76 lost when Security Policy re-installed, AA-345
using fully automatic sign on, AA-93 terminating, WI-215
using partially automatic sign on, AA-92 connections table, AA-322, AA-325
Client Encryption connections, enabling outgoing, OL-110
meaning of Destination, VP-90 contains operator, AM-33
CLIENT keyword Content Vectoring Server, see CVP Server
$FWDIR/conf/masters file, AA-350 control connection
Client/Server deployment of Management accepting, WI-143
Module, AA-224 authentication and encryption, WI-143, OL-109
clients file, AA-377 encrypting, AA-347
clocks control information
synchronizing for SKIP, VP-132 sending to Kernel Module, AA-275
code.def file, AA-380 Control Properties, OL-107
displaying windows, WI-8, OL-21
interaction with Rule Base, OL-132
LEGEND
FireWall-1
Index-iv FireWall-1 User Guide Master Index • September 1998

settings for SecuRemote Client, VP-92 default Security Policy, GS-66, AA-319, AA-320,
Control Properties windows, OL-21 AA-380
control.map, AA-348 restrictions under IBM AIX, GS-59
access operations, list of, AA-349 verifying that it is loaded, AA-320
control.map file, AA-380 default.bin file, AA-384
modified during FireWall-1 reconfiguration, AA-345 default.fc file, AA-384
CoolTalk, AA-322 default.ft file, AA-384
enabling back connections, AA-388 default.lg file, AA-384
cpp file, AA-376 default.pf file, AA-380, AA-384
creating an object in the LDAP directory, AM-24 default.W file, AA-378
creating groups, GS-34 default_server, WI-124, OL-98
crypt.def file, AA-380, VP-98 default_server parameter
ctlver file, AA-384 smtp.conf, AA-111
CU-SeeMe, AA-394 defaultfilter, AA-380
CVP checking defaultfilter.boot file, AA-380
URI resource, OL-87, OL-97, OL-100 defaultfilter.drop file, AA-380
CVP Inspection deffunc, AA-311
step by step procedure, AA-133 define, AA-302, AA-311
CVP inspection difference between define and #define, AA-302,
FTP resource, WI-131 AA-311
SMTP resource, WI-127 DES
URI resource, WI-123 using ACE (SecurID) DES with FireWall-1, AA-365
CVP Server, AA-378, WI-98 Destination Selection window, WI-228, WI-230,
defining, OL-78 OL-159, OL-164
how it is invoked, AA-129 dest-unreach, AA-398
step by step procedure for using, AA-133 Different Routes for Connections, AA-230
CVP Server Properties window, WI-98, OL-78 Diffie-Hellman scheme, VP-3
Digital Signature, VP-4
D direction of enforcement, AA-367
data field values directory
of rule, modifying, OL-130 installing FireWall-1 in a directory other than the
date , AA-309 default directory, GS-43
Date Selection Criteria window, WI-226 discard, AA-388, AA-394
day, AA-309, OL-59 display_bat file, AA-376
daytime, AA-388, AA-394 displaying
DB Download, WI-64, OL-56 System Status View Window, GS-11, GS-128,
DCE-RPC, AA-390, AA-397 WI-202, OL-145
required by MS Exchange, AA-322 distributed FireWall-1 configuration
DecNET diagram, GS-36
inspecting, AA-365 distributed management
Decryption on Accept, OL-110 configuring FireWall-1 for, AA-345
default directory DN
FireWall-1, GS-43 logging in using, AA-152
default rule, GS-91 DNS, AA-388, OL-68
LEGEND
FireWall-1
Master Index Index-v

encryption in SecuRemote, VP-93, VP-97 and synchronized FireWalls, AA-233
reverse resolving IP addresses using, OL-54 basic definitions, VP-1
dns, AA-394 changing keys, VP-32
DNS, dual, AA-354 communications with external networks, VP-30
dnsinfo file, AA-378 configuration examples, VP-17
dnsinfo.C file, AA-285 DNS, VP-97
domain incompatible with FASTPATH, AA-325
defining properties of, OL-28, OL-53 key hierarchy, VP-24
load balancing algorithm, AA-237 key management, VP-16
using a domain object in a rule, WI-34, OL-53 using with Address Translation on the same
Domain Name Download, WI-144, OL-111, OL-115 system, AA-213
domain name download, enabling, WI-144, WI-149, Virtual Encryption Session, VP-23
OL-111, OL-115 encryption algorithm
Domain Name Queries, WI-144, OL-111, OL-115 choosing for SecuRemote users, VP-59
domain name queries, enabling, WI-144, WI-148, encryption domain, VP-16
OL-111, OL-115 Encryption Module, GS-81
Drop installing on Bay Networks and Xylan, GS-77
differences from Reject, WI-167, OL-125 Encryption Properties window, VP-56
dropping an application, WI-173, OL-132 encryption rule
dup.def file, AA-380 integrating in a Rule Base, VP-22
encryption scheme mismatch, WI-148, OL-114,
E VP-39
echo, AA-388, AA-394 End User License Agreement, AM-8
echo-reply, AA-355, AA-398 ends with operator, AM-33
echo-request, AA-355, AA-398 Enforcement Point
egp, AA-399 definition of, GS-73
eht_set.C file, AA-380 enforcing and installing, difference between, WI-173,
Elapsed column OL-133
method of calculation, WI-214, WI-215, OL-153, enterprise ID, AA-242
OL-154 ENTRUST Certificate Authority, VP-46, VP-122
embedded systems Entrust Certificates, VP-122
where to install license, GS-69 Entrust Public Key Infrastructure, VP-45
Enable Domain Name Download, WI-144, WI-149 Entrust users
Enable Domain Name Queries, WI-144, WI-148 creating profiles, VP-123
Enable ICMP, WI-144, WI-149, OL-108 recovering profiles, VP-123
Enable Outgoing Packets, WI-144 ENTRUST.INI file, VP-122
Enable Outgoing Packets property, AA-368 error message
Enable Response of FTP Data Connections, WI-145, "connection to original-MTA failed", AA-361
OL-112 No Response from Server, WI-6
Enable RIP, WI-144, WI-148 error_server parameter
Enable UDP Replies, WI-143 smtp.conf, AA-111
encapsulation established TCP, WI-48, OL-47
SecuRemote, VP-94 established TCP connections , AA-322
encryption enabling, OL-115
LEGEND
FireWall-1
Index-vi FireWall-1 User Guide Master Index • September 1998

established TCP packets, WI-147, OL-114 field, data
established TCP sessions, AA-322 modifying value of, OL-130
evaluation license Find Date, WI-222
ordering, GS-69 Find in all Fields window, WI-223
evaluation package Find menu, WI-223
license for, GS-69 Find window, WI-222
Excessive Log Grace Period, WI-146, OL-113 finger, AA-388
exec, AA-388 FireWall, GS-76, AA-221
expiration, OL-59 FireWall daemon
expires, AA-303 stopping, AA-256
explicitly defined rules FireWall Inspection Components, AA-292
interaction with implicit rules, WI-177 FireWall Module, GS-81
Exportable description of, AA-223
checkbox in Host Properties window, VP-87 minimum requirements (Windows), GS-40
Extended Encryption Protocol, VP-140 starting, AA-256
external FireWall Module FireWall Module and Inspection Module, differences
not managed by FireWall-1/n, GS-79, AA-365 between, GS-76, AA-221
external FireWalled object, WI-22, WI-32, WI-36, FireWall Modules
WI-49, WI-54 restrictions on synchronization, AA-232
external group, AA-141 FireWall Synchronization
creating, WI-75 example, AA-230
deleting, WI-78 implementation, AA-230
modifying, WI-78 FireWall synchronization
when changes take effect, WI-75, WI-78 overview, AA-229
external interface FireWall-1
hiding IP address, AA-159, VP-86 administrative issues, AA-369
not set by this loading before installing, GS-31
error message, AA-337 configuration, AM-3
of gateway, specifying for ISAKMP/ Home Page, GS-29
OAKLEY, GS-33, VP-28 installing in a directory other than the default
of gateway, specifying for SKIP, VP-25 directory, GS-43
reconfiguring, AA-337 killing the daemon and fw stop, difference
specifying IP address of, VP-131 between, AA-369
external interfaces mailing list, GS-29
restricted in FireWall-1/n, GS-79, AA-364 performance, GS-24
external users reconfiguring, AA-254, AA-255
managing, WI-74 stopping, AA-369
external.if file, AA-337, AA-378 uninstalling, GS-68
modified during FireWall-1 reconfiguration, AA-345 upgrading to a new version of, GS-34
Web Page, GS-29
F FireWall-1
Fast mode, WI-85, OL-67 disabling (NT), GS-54
Fastpath, WI-85, OL-67 loss of state after upgrading, GS-35
fault tolerance, AA-373 reconfiguring (NT), GS-55
Fetch command (Named Masks window), WI-182
LEGEND
FireWall-1
Master Index Index-vii

stopping (NT), GS-54 definition of, GS-73
stopping inspection (NT), GS-54 FireWalled host
uninstalling (NT), GS-54 definition of, GS-73
uninstalling (Unix), GS-68 displaying status of, AA-264
FireWall-1 Adapter FireWalled, defined, GS-4
removing, VP-110 first IP address, AA-177
restrictions on adding and removing, VP-93 first port, AA-178
FireWall-1 authentication password format file
installing, AA-261 name displayed in status bar, WI-213
FireWall-1 components on different machines format lists, AA-308
communication between, AA-345 formats.def file, AA-380
FireWall-1 Control Connections, OL-109 free function, AA-303
FireWall-1 daemon FreeTel, AA-322, AA-394
sending signal to, AA-278 FTP, GS-18, AA-29, AA-321, AA-325, WI-85,
FireWall-1 driver OL-67
loading process, AA-404 authenticated session, description of, GS-19
FireWall-1 FireWall daemon authenticating through the HTTP Security
stopping, AA-256 Server, AA-358
FireWall-1 FireWall Module back connection, AA-345
starting, AA-256
back connections, encrypting, VP-71
FireWall-1 HP OpenView Extension
data connection, AA-345
installing, AA-244, AA-245, AA-246
data connection, enabling response of, WI-145,
specifying the Management Server for FireWalled
OL-112
objects, AA-247
file names logged for authenticated
FireWall-1 HP OpenView extension
sessions, AA-103, WI-218, OL-155
default SNMP port for FireWalled objects, AA-246
from HTTP, AA-355
FireWall discovery, AA-246
get and put logged for User Authenticated
FireWall-1 license, see license
FTP, AA-103
FireWall-1 password
PORT command, AA-345
advantage over OS password, AA-30
FireWall-1 SNMP daemon, AA-241 User Authentication, GS-18, AA-29
FireWall-1 software using with SecuRemote Client, VP-92
installation problems, GS-67 ftp, AA-388
reconfiguring, GS-68 ftp back connections
upgrading, GS-67 encrypting, VP-71
FireWall-1 version number FTP daemon, AA-356
displaying, AA-267 FTP data connections, AA-321, AA-388, WI-145
FireWall1, upgrading to a new version of FTP PASV, AA-321
objects carried over from previous version, GS-34 enabling FTP Passive Connections, WI-145,
FireWall-1/n products OL-112
restrictions, GS-79, AA-364 FTP PASV connections, OL-112
FireWall-1license FTP proxy
installing, GS-69 defining to browser, AA-355, AA-358
obtaining, GS-69 FTP resource
FireWalled gateway CVP inspection, WI-131
LEGEND
FireWall-1
Index-viii FireWall-1 User Guide Master Index • September 1998

matching, AA-108 fw1enc-fwz-expiration, AA-148, AM-39
FTP resources fw1expiration-date, AA-148, AM-39
command matching, AA-108 fw1groupTemplate, AA-149, AM-40
file name matching, AA-108 fw1hour-range-from, AA-148, AM-39
matching, AA-108 fw1hour-range-to, AA-148, AM-39
fw command, AA-256 fw1person, AM-34, AM-35
fw converthosts, AA-285 fw1pwdLastMod, AA-147, AA-151, AM-38
fw ctl, AA-275 fw1Skey-mdm, AA-147, AM-38
fw dbimport, AA-287 fw1Skey-passwd, AA-147, AM-38
fw fetch command, AA-259 fw1Skey-seed, AA-147, AM-38
fw file, AA-376 fw1sr-auth-track, AA-149, AM-40
fw gen command, AA-278 fw1SR-datam, AA-148, AM-39
fw kill, AA-383 fw1SR-keym, AA-148, AM-39
fw lichosts command, AA-265 fw1SR-mdm , AA-148, AM-39
fw log command, AA-265 fw1template, AM-35
fw logswitch command, AA-260 fwa1, AA-262
fw printlic, AA-262 definition of, AA-349
fw printlic command, AA-268 fwa1 authentication, AA-350
fw putkey, AA-261, AA-341, AA-351 fwalert file, AA-376
fw putlic command, AA-261, AA-262 fwauth.keys file, AA-378
fw sam command, AA-269 modified during FireWall-1 reconfiguration, AA-345
fw stat command, AA-264 fwauth.NDB file, AA-378, AA-379
fw tab command, AA-283 fwauth.NDB7 file, AA-378
fw unload command, AA-259, AA-266, AA-267 fwauth.NDBBKP file, AA-378
fw.alog file, AA-383 fwauthd.conf, AA-97
fw.alogptr file, AA-383 fwauthd.conf file, AA-378
fw.conf file, AA-383 modified during FireWall-1 reconfiguration, AA-345
fw.info file, AA-380 fwav file, AA-376
fw.license file fwav.conf file, AA-378
modified during FireWall-1 reconfiguration, AA-345 fwavstart file, AA-376
fw.log file, AA-383 fwavstop file, AA-376
fw.logptr file, AA-383 fwc, AA-279
fw.logtrack file, AA-383 fwc file, AA-376
fw.mkdev file, AA-383 fwcisco file, AA-376
fw.sys file, AA-383 fwciscoload, AA-273
fw.vlog file, AA-383 fwciscoload file, AA-376, AA-377
fw.vlogptr file, AA-383 fwcmsd.exe file, AA-376
FW1_clntauth, AA-97 fwcomp file, AA-376
fw1allowed-dst, AA-148, AM-39 fwconfig
fw1allowed-src, AA-148, AM-39 installing a license using, AA-262
fw1allowed-vlan, AA-148, AM-39 fwconfig file, AA-376
fw1authmethod, AA-146, AM-37 fwconn.h file, AA-380
fw1auth-server, AA-147, AM-38 fwctrnm.h file, AA-380
fw1day, AA-148, AM-39 fwctrs.h file, AA-380
LEGEND
FireWall-1
Master Index Index-ix

fwctrs.ini file, AA-380 fwxauth file, AA-377
fwd file, AA-376 fwxlconf, AA-189, AA-283
fwd.h file, AA-337 fwxlconf file, AA-377
fwd.hosts file, AA-337
fwd.pid file, AA-384 G
FWDIR gateway
importance of setting correctly, GS-43 cannot connect through, AA-335
fwell file, AA-376, AA-385 defining network object as, WI-22, OL-33
fwf2htbin.gif file, AA-380 defining properties of, OL-23, OL-28, OL-83
fwf2htdir.gif file, AA-380 getting its key before installing a Security Policy on
fwf2htunknown.gif file, AA-380 it, VP-53, VP-54
fwinfo debugging tool hiding IP address of external interface, AA-159,
incorrect functioning, GS-43 VP-86
fwinfo file, AA-376 specifying communication direction of rules
fwinfo.pmr file, AA-376 on, WI-142, OL-109
fwinfo2 file, AA-376 gateway, protecting, GS-91
fwinstall file, AA-376 gateways
fwlv file, AA-376 defining interfaces as separate objects, AA-355
fwlv.info file , AA-380 direction of enforcement on, AA-368
fwm file , AA-376 generic services
fwm.pid file, AA-384 service properties, WI-88, OL-73
fwmod.* files, AA-383 generic user, AA-325, WI-72, OL-61
fwmusers file, AA-378 ggp, AA-399
fwntperf.dll file, AA-381 Global Pool, AA-201
fwopsec.conf file, AA-271, AA-378 gopher, AA-388
fwrl.conf file, AA-378 GoTo Menu, OL-169
fwrlconf file, AA-384 gps.pro file, AA-381
fwsngui file, AA-376 grace period between logs of similar packets, OL-113
fwsnmp.dll file, AA-381 greater than operator, AM-33
fwstart, GS-59, AA-234, AA-277 compatibility with LDAP versions, AM-33
fwstart file, AA-376 group
fwstop, GS-59, AA-277, AA-383 form of DN, AM-59
groups
and killing the FireWall-1 daemon, difference
adding elements to, OL-57, OL-65
between, AA-369
defining properties of, OL-28
fwstop file , AA-376
GUI Client
fwui file, AA-376
minimum requirements, GS-39, VP-105
fwui.log file, AA-383
GUI Clients
fwui_head.def file, AA-381
adding or deleting, AA-224
fwui_trail.def file, AA-381
GUI windows
fwuninst file, AA-376
closing, WI-8, OL-21
fwuninstall file, AA-376
displaying, WI-8, OL-21
fwuserauth.NDB file, AA-379
gui-clients file, AA-378
fwx_translation table
explanation of fields in, AA-215
LEGEND
FireWall-1
Index-x FireWall-1 User Guide Master Index • September 1998

H HTML, AA-380
H.323, AA-322, AA-325, AA-389, WI-85, OL-67 HTML Weeding, WI-123
enabling back connections, AA-389 HTML weeding, AA-380
hashsize, AA-303 HTTP
heuristic check of Rule Base, WI-173, OL-131 allowing FTP sessions from, AA-355
hidden rules, WI-178 blocking JAVA applets, OL-87
displaying, WI-179 restricting inbound, AA-48
unhiding, WI-179 restricting internal user’s access to JAVA
Hide mode, AA-159 applets, OL-87
Hide Repeating Lines option, OL-165 restricting outbound, AA-48
Hide/Unhide menu, WI-219 User Authentication, GS-18, AA-29
hiding IP addresses, AA-369 using a Server for Null Requests, AA-60
hiding rules, WI-178 using reauthentication options, AA-47
High Availability, AA-229 http, AA-388
encrypting connections between synchronized HTTP Authenticating Server
FireWalls, AA-233 blocking JAVA applets, OL-87
SKIP, AA-233 HTTP Security Server
synchronizing different version FireWall as proxy, AA-112
Modules, AA-233 configuring multiple ports, AA-56
synchronizing FireWall Modules on different defining as a Security Proxy, AA-51
platforms, AA-232 defining as an HTTP proxy, AA-50
synchronizing FireWall Modules with different error messages, AA-56
Security Policies, AA-233 overview, AA-44
high availability putting a proxy behind, AA-45
Account Units, AM-5 support for FTP, AA-112
hijacking sessions, AA-363 support for HTTPS, AA-113, AA-116
HKEY_LOCAL_MACHINE, AA-401 HTTP Servers
hostname command, AA-353, VP-131 defining, AA-46
hosts HTTPS, AA-366
defining network objects as, WI-22, OL-33 authenticating outbound, AA-51
defining properties of, OL-23, OL-28 using URI Resource rules with, AA-116
direction of enforcement on, AA-368 with non-transparent authentication, AA-60
list of those protected by FireWall-1/n https, AA-388
product, AA-265
hosts file, GS-33, AA-370, WI-22, WI-36, OL-28, I
OL-38 IANA, AA-170, AA-366
Hosts, Gateways and Interfaces IBM AIX
distinction between, AA-353 IP Forwarding, GS-59
hour, OL-59 overwriting previous installation, GS-59
HP separate JRE installation, AM-13
FireWall-1 HP OpenView extension, AA-243 X/Motif library version, GS-59
HP OpenView, see FireWall-1 HP OpenView extension icense
HP-UX 10 overwriting, AA-263
transitional links option, GS-56 ICMP, WI-144, WI-145, OL-111
LEGEND
FireWall-1
Master Index Index-xi

accepting, OL-116 date, AA-309
enabling, WI-144, WI-149, OL-111, OL-116 day, AA-309
match string, WI-88, WI-89, OL-72, OL-73 day in month specification, AA-300
ICMP Redirect day in week specification, AA-300
enabling, WI-145, WI-149, OL-111, OL-116 delete, AA-306
ident, AA-389 direction, AA-310
igrp, AA-399 drop, AA-312
imap, AA-389 dynamic tables, AA-304
implicit drop rule , GS-91 elements of a rule, AA-295
implicit rules expcall attribute, AA-305
interaction with explicitly defined rules, WI-177 expires attribute, AA-305
toggling display of, WI-10 export, AA-312
Implied Pseudo-Rules option on View menu , WI-178 format lists, AA-308
implies, AA-303 function definitions, AA-311
in.aclientd file, AA-377 get, AA-304
in.aftpd file, AA-377 hex, AA-308
in.ahttpd file, AA-377 hold, AA-313
in.arlogind file, AA-377 host, AA-310
in.asmtpd file, AA-377 identifier names, AA-301
in.atelentd file, AA-377 ifaddr, AA-310
in.lhttpd file, AA-377 in, AA-313
in.telnetd, AA-356 include files, AA-298
incoming communications Install On, AA-296
Security Policy enforced on, AA-367 int, AA-308
inetd.conf, AA-356 interface, AA-310
inetOrgPerson, AM-34, AM-35 IP address constant, AA-300
Info field ipaddr, AA-308
get and put logged for authenticated FTP, WI-218, keep attribute, AA-305
OL-155 limit attribute, AA-305
info-reply, AA-398 lists, AA-307
info-req, AA-398 log, AA-313
inhibiting connections, AA-269
LOG macro, AA-316
init.def file, AA-381 macros, AA-316
inode , AA-383 modify, AA-306, AA-314
inside net, WI-59, OL-52
name resolution, AA-301
INSPECT
netof, AA-314
accept, AA-310
nexpires attribute, AA-305
backwards compatibility, AA-311
numeric constants, AA-299
call, AA-311
operators, AA-309
compatibility between FireWall-1 versions, AA-311
packetid, AA-310
compiler, AA-279
port, AA-308
compound conditions, AA-294
pre-processor, AA-300
constants, AA-299
preprocessor, AA-316
current packet, AA-310
proto, AA-308
LEGEND
FireWall-1
Index-xii FireWall-1 User Guide Master Index • September 1998

record, AA-306, AA-314 installation
refresh attribute, AA-305 HP-UX, AM-10
reject, AA-314 IBM AIX, AM-12
reserved words, AA-299 Solaris, AM-9
rule, elements of, AA-295 Unix, AM-9
scope, AA-296 Windows, AM-8
segment register, AA-301 installing
service, AA-308 router access list, WI-200, OL-142
set, AA-314 Rule Base on hosts, OL-148
static tables, AA-307 Security Policy, WI-193
string, AA-308 installing a FireWall-1 authentication
tables, AA-302 password, AA-261
time specification, AA-299 installing a FireWall-1 license, GS-69
tod, AA-309 installing a FireWall-1 license, AA-262
Track, AA-296 installing and enforcing, difference between, WI-173,
TRAP macro, AA-316 OL-133
uint, AA-308 installing FireWall-1, GS-31
vanish, AA-315 installing the Account Management Client, AM-8
INSPECT tables Insufficient Information problem , AA-104
displaying, AA-283 Integrated FireWalls
Inspection Code general properties, WI-53
compiling from Inspection Script, WI-174, OL-133 PIX setup, WI-56
installing, AA-317, OL-138 TimeStep setup, WI-55
Inspection Code Loading, WI-196, OL-61, OL-139 Integrated Firewalls, WI-52
Inspection Module interface data
architecture, GS-13 fetching automatically, WI-24
defined, GS-4 Interface names
fetching last installed on host, AA-259 Bay routers, AA-222
network objects allowed to load, AA-378 Interface Selection Criteria window, WI-227
Inspection Module and FireWall Module, differences Interface Selection dialog box, WI-227, OL-158
between, GS-76, AA-221 interfaces
Inspection Module tables, displaying, using command- aliased, AA-363
line interface, AA-283 defining a gateway's interfaces as separate
Inspection Script objects, AA-355
backwards compatibility, AA-311 defining as an object, AA-355
compiling, AA-279, AA-317 how Security Policy is enforced on
compiling Inspection Code from, WI-174, OL-133 different, AA-367
generating from Rule Base, AA-278 network, properties of, WI-24, OL-33, OL-40
generating using command-line interface, AA-278 result of failing to define, WI-23, WI-24, OL-34
manually editing, WI-174, OL-133 virtual, AA-363
viewing, WI-194, OL-137 interfaces, external
restricted in FireWall-1/50 and FireWall-1/
writing, AA-292
250, GS-79, AA-364, AA-365
Install On field
internal FireWalled object, WI-22, WI-32, WI-36,
NAT tab, AA-173
WI-49, WI-54
LEGEND
FireWall-1
Master Index Index-xiii

internal hosts ISAKMP, AA-394
number restricted in FireWall-1/n, GS-79, AA-364 reply packets not returning, VP-131
too many, AA-337 ISAKMP negotiations
internal interfaces logging, VP-38
not restricted in FireWall-1/n, GS-79, AA-364 ISAKMP SA
internal network objects, WI-64, OL-24, OL-84 expiration in the course of an encrypted
internal password, AM-48 session, VP-38
advantage over OS password, AM-48 ISAKMP/OAKLEY
Internet specifying the encrypting gateway’s IP
defining to FireWall-1, AA-352 address, GS-33, VP-28
InternetPhone, AA-394 ISDN interfaces, AA-366
intrap, AA-303
intruders J
blocking connections from or to suspected, WI-215 JAVA, WI-123, OL-87
IP Address, WI-32, WI-49 blocking JAVA applets, WI-123, OL-87
IP addresses Java
hiding, AA-369 separate installation for IBM AIX, AM-13
resolving updated, if modified, OL-171 version required for Account Management
unregistered, AA-369 Client, AM-13
when does changing take effect, AA-345 JAVA applets
which to use when directing logging to, AA-328 already in cache, WI-123, OL-87
IP Forwarding, GS-34, AA-275 Java Runtime Environment, see JRE
controlling status of with FireWall-1, AA-275 JAVA Script, WI-123, OL-87
JRE
enabling and disabling, AA-276
installing on IBM AIX, AM-13
enabling and disabling on HPUX 10, AA-276
enabling and disabling on IBM AIX, AA-277
K
enabling and disabling on Solaris 2, AA-276
kbuf, AA-303
enabling and disabling on Windows NT, AA-277
keep, AA-303
IBM AIX, GS-59, AA-275, AA-277
Kerberos, AA-365
IP Options, AA-363, WI-147
kerberos, AA-389, AA-394
track dropping of, OL-114
Kernel Module
IP Tunnels, WI-43
sending control information to, AA-275
IPSec
kerntabs.h file, AA-381
reply packets not returning, VP-131
kertabs.def file, AA-381
IPSec session key
keys
expiration in the course of an encrypted
fetching over Internet, VP-26, VP-30, VP-48,
session, VP-38
IPX VP-49, VP-53, VP-54, VP-71
inspecting, AA-365
IPX packets L
inspecting, AA-365 last IP address, AA-177
irc, AA-389 last port, AA-178
is not operator, AM-33 LDAP, WI-74
is operator, AM-33 Account Unit, AA-139, AA-140, AM-4
defining users in both LDAP and
LEGEND
FireWall-1
Index-xiv FireWall-1 User Guide Master Index • September 1998

FireWall-1, AA-142, AA-154 license.rtf, AM-8
exporting users from the FireWall User license.txt, AM-8
Database, AA-152 limit, AA-303
port number for SSL connection, WI-106, AM-1 Little Endian, AA-315
port number for standard connection, AM-1 live connections, AA-240, OL-154
schema checking, AA-153 LiveLan, AA-389
security issues, AA-153 lmhosts file, GS-33, AA-370, WI-22, WI-36,
version with which FireWall- is compliant, AA-152 OL-28, OL-38
LDAP Account Unit Load Agents
step by step instructions on how to use in Security defining parameters, WI-155, OL-121
Policy, AA-140 Load Agents Port property, AA-240
LDAP Server Load Balancing, AA-234
enabling connections from FireWall Module defining parameters, WI-155, OL-121
to, OL-109 step by step instructions, AA-237
SSL, AM-18 load balancing algorithms, AA-236
LDAP server, see also Account Unit
Load Measurement Interval property, AA-240
LDAP servers
Load Measuring, AA-239
indexing, AA-153
load_agent file, AA-377
optimizing, AA-153
loading a Security Policy, AA-257
ldap service, AA-389
local.arp, AA-384
LDAP Version 2.0, AA-152
local.arp file, AA-168
LDAP Version 3.0, AA-152, AM-18, AM-33
locking, AA-383
LDAPservers
locking mechanism
defining, WI-102
used to prevent simultaneous updates, AA-225
ldap-ssl, AA-389
lockmanager, AA-397
LDIF syntax, AA-288
Log
less than operator, AM-33
rule number zero, AA-362
compatibility with LDAP versions, AM-33
rule with negative number, AA-362
libsun_av.so file, AA-381
log
license
established TCP packets, AA-324
confirming that you are using correct
grace period between similar packets, OL-113
licenses, GS-70
printing, WI-239, OL-172
deleting, AA-263
redirect logging to another Master, AA-327
displaying, AA-268
saving, WI-239, OL-172
for evaluation package, GS-69
scrolling, WI-222, OL-157
installing, GS-69, AA-262
viewing, WI-211, OL-151
installing on host, AA-261, AA-262
Log entries, selecting by
obtaining, GS-68
additional information, WI-233
printing, AA-268
destination, WI-227
reconfiguring with fwconfig, GS-61, AA-255
DstKeyID, WI-233
removing, AA-263
information, WI-233
removing old licenses, GS-69
interface, WI-227
where to install, GS-68
number, WI-226
where to install for embedded systems, GS-69
origin, WI-227
LEGEND
FireWall-1
Master Index Index-xv

port, WI-226 Access Control, AA-225
rule, WI-226 packets as dropped though connection
service, WI-227 continues, AA-324
source, WI-227 redirecting to additional Masters, AA-327
SrcKeyID, WI-233 redirecting to another Master, AA-327
type, WI-230 when the FireWalled Gateway is not the Management
user, WI-227 Station, AA-327
Log File where to direct, AA-378
creating new, AA-260 Logging and Alerting
deleting, WI-239 Security Policy, WI-146, OL-113, VP-38
displaying contents of, AA-265 Logical Servers, AA-237
exporting, AA-266, WI-240 step by step instructions on using, AA-237
miscellaneous functions, WI-239 using HTTP Logical Servers in rule, AA-239
name displayed in title bar, WI-213 logical servers, WI-61, OL-25
opening another, WI-238 persistent server mode, AA-238
printing, WI-239 login, AA-389
reload, WI-240 with DN or user name, AA-152
saving, WI-239 logviewer.C file, AA-378
starting a new, WI-239 Lotus Notes, AA-389
stop updating, WI-240
log file M
analysis of, AA-362 Mail Alert Command, WI-147, OL-113
creating new, OL-171 manage.lock file, AA-225, AA-383
creating new, using command-line Management Module
interface, AA-260 definition of, GS-74
deleting, OL-171 description of, AA-223
displaying, using command-line interface, AA-265, Management Point
AA-269 definition of, GS-74
exporting to ASCII file, AA-266 Management Server, AA-279
managing, WI-238, OL-171 definition of, GS-74
navigating and searching in, WI-222, OL-169 description of, AA-224
periodically switching, AA-363 minimum requirements (Unix), GS-55
saving, WI-239, OL-172 minimum requirements (Windows), GS-39
searching for a text string in, WI-223, OL-170 name displayed in status bar, WI-213
statistical analysis of, AA-362 name of executable, AA-224
LOG macro, AA-316 problems in connecting to, WI-5
Log Server timeout in connecting to, WI-6
definition of, WI-212 Management Station
Log Viewer, GS-128, WI-211, OL-151 definition of, GS-74
displaying, WI-8, OL-21 Managing 3Com Filters
hiding data fields, OL-157 routers, WI-47, OL-46
nothing in, AA-340 mangling
packets of an established TCP connection, AA-315,
selection criteria, WI-225, OL-157
logging AA-323, AA-324
LEGEND
FireWall-1
Index-xvi FireWall-1 User Guide Master Index • September 1998

masking rules, WI-178 minimum requirements
mask-reply, AA-398 Account Management Client, AM-7
mask-request, AA-398 FireWall Module, GS-40
masks FireWall Module (Windows), GS-40
applying, WI-183 FireWall-1 (Unix), GS-55
Master GUI Client, GS-39
defining a network object as, AA-378 GUI client, GS-39, VP-105
fetching Security Policy from, AA-259 Management Server, GS-39, GS-55, AM-7
redirect logging to additional Masters, AA-327 Management Server (Unix), GS-55
redirect logging to another Master, AA-327 Management Server (Windows), GS-39
redirecting logging to another Master, WI-239 SecuRemote Client, VP-105
which IP address to use when directing logging Unix platforms, GS-55
to, AA-328 modem connections
MASTERS securing, AA-364
parameter in control.map file, AA-348 modtrap, AA-303
masters file monitoring system status, GS-128, WI-201, OL-145
description of, AA-378 Mosaic, AA-390
modified during FireWall-1 reconfiguration, AA-345 mountd, AA-397
MASTERS keyword MS Exchange, AA-322
$FWDIR/conf/masters file, AA-348 multicast, AA-367
match, WI-88, WI-89, OL-72
multiple adapters, VP-109
memory usage, AA-372
MIB, AA-242 N
chkpnt.mib file, AA-242
name, AA-177, AA-178, AA-394, WI-84, WI-86,
chkpnt.mib file source code, AA-248 WI-87, WI-88, WI-91, OL-72, OL-73
location, AA-382 named, WI-144, WI-149
mib.txt file, AA-382
nbdatagram, AA-394
mib.txt2 file, AA-382 nbname, AA-394
RFC support, AA-241 nbsession, AA-390, WI-48, OL-47
Wellfleet, AA-385
NBT, AA-390
mib.txt file, AA-382 NDIS3.1, VP-103
Microsoft Conferencing, AA-389 negate rules, WI-47, OL-46
Microsoft Exchange, AA-390
net mask, WI-32
Microsoft NetMeeting, AA-390 NetBEUI, see NBT
Microsoft NetShow, AA-390 NetShow, AA-322
Microsoft RRAS, WI-44 netstat, AA-390
Microsoft SQL Server, AA-390 network configuration
MIME modifying, VP-109
stripping specified types of attachments from network interface properties, WI-24, OL-33, OL-40
message, WI-126, OL-97 network object
MIME attachments creating, GS-108, GS-121, GS-122, WI-18
definable in an SMTP Resource, WI-126, OL-97
creating groups of network objects, WI-59
definition syntax in SMTP Resource, WI-126,
defining, WI-15, OL-23, OL-75, OL-83
OL-97 defining properties of, OL-23, OL-28, OL-83
LEGEND
FireWall-1
Master Index Index-xvii

deleting, WI-19, OL-27, VP-67 creating in LDAP directory, AM-24
editing existing, WI-19, WI-96, OL-26, OL-84 objects.C file, AA-43, AA-378, AA-379
group, WI-59, WI-107, WI-139, OL-81, omi.conf file, AA-379
OL-106 On Line option, OL-165
group, adding service to, WI-91 one-time passwords, VP-121
group, defining properties of, WI-68, OL-65, OnTime , AA-395
OL-102 Open Platform for Secure Enterprise Connectivity, see
group, deleting service from, WI-92 OPSEC
internal, WI-64, OL-24, OL-84 Open Security Extension, GS-81
modifying, WI-19 Open Windows, AA-391
properties, WI-15, WI-93, WI-94, OL-23, OpenView, see FireWall-1 HP OpenView extension
OL-75, OL-83, OL-103 OPSEC, AA-128, AA-133
network object group OPSEC-certified products
deleting from, WI-60 obtaining evaluation copies, AA-128, AA-133
network object properties Options window, WI-237
resolving updated, if modified, OL-171 options.conf file, AA-379
network objects organization, AM-25
limit of 240 objects in XView menu, OL-32 Organizational Unit
which are on my network?, AA-352 creating, AM-24
Network Objects Manager, OL-24, OL-84 organizationalPerson, AM-34, AM-35
displaying, WI-8 organizationalUnitName, AM-24
Network Objects Manager window, OL-20 OS Password, AM-47
NFS, AA-397 ospf, AA-399
nfsd, AA-394 outgoing communications
nfsprog, AA-397 Security Policy enforced on, AA-367
NIS, AA-397 outgoing connections, enabling, OL-110
nisplus, AA-397 outgoing packets
nntp, AA-390 accepting, WI-144
node outtrap, AA-303
definition of, GS-74 Overview, GS-4, AM-1
nodes overwriting previous AIX installation, GS-59
number restricted in FireWall-1/n, GS-79, AA-364
Non-Transparent Authentication P
and HTTP, AA-58 packet filter
Non-transparent Authentication installing Security Policy on, WI-197, OL-139
prompt_for_destination parameter, AA-43 Packet Key, VP-24
Notify Sender on Error field, AA-361 packet reassembly, AA-363
NT and Unix security risks associated with, AA-363
syntax differences, AA-253 param-prblm, AA-398
ntp, AA-391, AA-395 password
Number Selection Criteria window, WI-226 echoing, VP-121
erasing, VP-121
O expiration, VP-121
object limitation on length in Windows, GS-48
LEGEND
FireWall-1
Index-xviii FireWall-1 User Guide Master Index • September 1998

verifying, AA-146, AM-37 Power Management
password expiration, AA-151 possible conflict with SecuRemote, VP-94
PASV PPP, AA-365
enable FTP PASV, WI-145 pre-processor directives, AA-316
enabling FTP Passive Connections, WI-145, pre-processor statements, AA-316
OL-112 pre-shared secret, AA-151
pcnfsd, AA-397 printing
Perfect Forward Secrecy, VP-63 log entries, WI-239, OL-172
performance printing a log
improving, AA-370 truncated fields, AA-340
monitoring on Windows NT platforms, AA-405 privilege level, AA-225
performance guidelines, AA-370 product.conf file, AA-271
Performance Monitor, AA-380 products.conf file, AA-379
period of vulnerability, AA-366 prog number, WI-87, OL-70
description of, AA-319 program number, WI-87
PERMIT/Gate prologue, WI-89, OL-72
setup, WI-55, OL-50 prologue, adding to rules, WI-89, OL-72, OL-73
person, AM-34, AM-35 prompt_for_destination
ping, AA-398 User Authentication, AA-43
allowing unrestricted, AA-355 properties
PIX Address Translation interaction with Rule Base, WI-177
managing, AA-199 network object, WI-15, WI-93, WI-94, OL-23,
PIX authentication, WI-59, OL-52 OL-28, OL-75, OL-83, OL-103
PIX blackbox of defined object, displaying, WI-82, OL-64
authentication properties, WI-56 of network interface, WI-24, OL-33, OL-40
encryption properties, WI-57 of service object, defining, WI-81, OL-63
location of management server, WI-59, OL-52 time object, WI-135
management guidelines, WI-59, OL-52 Properties button
PointCast, AA-391 displaying Control Properties windows using, OL-21
Policy, see Security Policy Properties Setup
pop2, AA-391 settings for SecuRemote Client, VP-92
pop3, AA-391 Properties Setup windows, WI-141
PopUp Alert Command, WI-147, OL-113 protocol, AA-179
port 161 which available on network?, AA-353
failure to bind to, AA-241 Protocol Selection Criteria window, WI-233
port 256, AA-234 Protocol Selection dialog box, OL-162
port number, WI-84 Protocol Selection window, WI-233
assigning in Address Translation Hide Protocol Type, OL-67
mode, AA-159 protocol type, WI-84
ports proxy
limiting access to specific ports, AA-355 putting behind FireWall-1 HTTP Authenticating
Ports Range Server, AA-45
defining, AA-178 Public Key
postmaster parameter certifying, VP-5
smtp.conf, AA-111
LEGEND
FireWall-1
Master Index Index-xix

Public Key Distribution System, VP-2 resources
Public Key Infrastructure, VP-45 and synchronized FireWalls, AA-233
defining properties of, OL-83
R restrictions
RADIUS, AA-30, AA-395, AM-48 data not encrypted, VP-93
defining server, WI-99 modifying the network configuration after installing
enabling connections from FireWall Module to SecuRemote, VP-94
server, WI-143, OL-109 power management, VP-94
Server Properties window, OL-79 removing and adding FireWall adapter, VP-93
RADIUS Servers TCP stacks supported by SecuRemote, VP-93
Server Groups, WI-107 timeout, VP-93
radius_versions , WI-100, OL-79 user password, VP-93
random reverse DNS, WI-118, OL-91
load balancing algorithm, AA-237 REXEC, OL-112
range of addresses, WI-61 rexec, AA-391
RAS, AA-391, AA-395 RFC 1155, AA-241
RDP, AA-395 RFC 1155 - 1213, AA-241
reading, further, GS-26 RFC 1156, AA-241
RealAudio, AA-322, AA-391 RFC 1157, AA-241
enabling back connections, AA-391 RFC 1521, WI-127, OL-97
using with SecuRemote Client, VP-92 RFC 1558, AM-33
re-configuration RFC 1631, AA-171
files modified during, AA-343, AA-345 RFC 1631 compliant Address Translation
reconfiguration options, AA-255 feature, AA-156
reconfiguring FireWall-1, AA-254, AA-255 RFC 1825, VP-8, VP-9
redirect, AA-398 RFC 1826, VP-9
refresh, AA-303 RFC 1827, VP-8
Refresh Network Database utility, OL-171 RFC 1828, VP-9
refreshing RFC 1829, VP-8
modified IP addresses, OL-171 RFC 1852, VP-9
Registry RFC 1858, WI-43, OL-43
FireWall-1 entries, AA-401 RFC 1918, AA-170
Reject RIP, WI-144, OL-110
differences from Drop, WI-168, OL-125 rip, AA-395
remote sites RIP, enabling, WI-144, WI-148, OL-110, OL-115
Account Units, AM-5 RLOGIN
Reply Timeout, WI-143, OL-110 User Authentication, GS-18, AA-29
resend_period parameter rlogin, AA-391
smtp.conf, AA-111
Rock Ridge format, GS-57, AA-244, AM-10
reserved port, OL-70 round robin
Resolve Address option, OL-165 load balancing algorithm, AA-237
resouce round trip
deleting, OL-85 load balancing algorithm, AA-237
resource Route Recording, WI-43
group, defining properties of, WI-132
LEGEND
FireWall-1
Index-xx FireWall-1 User Guide Master Index • September 1998

Router Access Lists deleting rule from, AA-188, WI-172, OL-129
importing, WI-197 display, WI-158, OL-124
managing imported access lists, WI-198 generating Inspection Script from, AA-278
verifying and viewing, WI-199 generating Inspection Script from, using command-
router interface line interface, AA-278
specifying name of, WI-38 interaction with Control Properties, OL-132
router_load.exe file, AA-377 interaction with Properties, WI-177
routers masking rules, WI-178
anti-spoofing capabilities, WI-39, OL-40 number of rules supported, AA-354
anti-spoofing on, WI-38, OL-39 sequential application of rules, exception
auto scoping, WI-38, OL-39 to, AA-104
defining network object as, OL-33 using ping in, AA-355
defining properties of, OL-38, OL-48 verifying, WI-173, OL-131
definition of, GS-74 Rule Base editor tabs, WI-158
installing access lists on, WI-200, OL-142 Rule Base Editor window, OL-21
installing Security Policy on, WI-170, WI-194, rule zero
OL-137 in Log Viewer, meaning of, AA-362, WI-218,
uninstalling access lists on, OL-142 OL-156
Routing and Remote Access Service, see Microsoft RRAS rulebases.fws file, AA-379
Routing Information Protocol, enabling, WI-144, rules
WI-148, OL-110, OL-115 adding and inserting, WI-160
routing problems, VP-143 adding to Rule Base, AA-180, WI-160, OL-128
RPC consistency and redundancy check of, WI-173,
enable FireWall-1 to control, WI-146, OL-112 OL-131
securing, GS-17 copying to clipboard, WI-161
service properties, WI-86, OL-70 cutting to clipboard, WI-161
RPC Control, AA-321 default, GS-91
RPC Services deleting, WI-160
restriction on use with SecuRemote, VP-92 deleting from Rule Base, AA-188, WI-172,
RRAS OL-129
see Microsoft RRAS direction of enforcement, GS-93, GS-96, OL-108
RSA, VP-104 disabling, WI-193
RSH, OL-112 hiding, WI-178
back connections, encrypting, VP-71
how executed, WI-157, OL-124
rsh, AA-391 masking, WI-178
RSH/REXEC, AA-321 modifying, WI-161, OL-130
rshell
modifying data field values, OL-130
and Address Translation, AA-171
pasting from clipboard, WI-161
rshell back connections
rules, see also Security Policy
encrypting, VP-71
rundir parameter
rstat, AA-397
smtp.conf, AA-111
Rule Base
rwall, AA-397
adding a new rule, AA-180, WI-160, OL-128
converting files for Client-Server
configuration, AA-280
LEGEND
FireWall-1
Master Index Index-xxi

S SecurID, AA-30, AA-274, AA-391, AA-395,
S/Key, AA-30, VP-121, AM-48 VP-121, AM-48
authentication specified in control.map file, AA-348 securidprop, AA-391
fwa1 authentication, AA-262 Security Policy
Secret Key minimum length, WI-68, WI-69, and ISDN interfaces, AA-366
OL-60, AM-49 backing up, AA-344
when a user forgets the password, AA-360 compiling, AA-257
SA creating new, WI-159
expiration in the course of an encrypted default, GS-66, AA-319, AA-320, AA-380
session, VP-38 downloading to Cisco router, AA-273
saving fetching from Master, AA-259
log entries, WI-239, OL-172 installing, WI-193
log file, WI-239, OL-172 installing on hosts, OL-148
scan_period parameter loading, AA-257
smtp.conf, AA-111 modified, when implemented, AA-369
schema checking, AM-46 opening, WI-159
Secret Key preventing two GUI Clients from simultaneously
sharing, VP-2 modifying, AA-383
Secure Socket Layer , AA-366 removing from selected hosts, OL-148
Secure Socket Layer, see SSL retrieving one installed on FireWall, WI-159
SecuRemote uninstalling, AA-259
and synchronized FireWalls, AA-234 viewing an installed Security Policy, WI-159
configuration example, VP-74, VP-86 Security Policy, see Rule Base
encapsulated session, VP-94 Security Servers
implementation, VP-73 configuration file, AA-123
other FireWalls along path from Client, VP-91 FTP resource matching, AA-108
other FireWalls along the path, VP-91 incoming connections, AA-107
restrictions, VP-91 interaction with OPSEC products, AA-120
SecuRemote Client outgoing connections, AA-107
and other firewalls along the path to the SecuRemote sending signal to, AA-278
Server, VP-91
using to authenticate other services, AA-125
responding to unauthenticated topology requests
Select menu, WI-224
from, VP-36
Selection, WI-237
SecuRemote connection
selection criteria for Log Viewer, WI-225, OL-157
reauthenticating, AA-151
selection criteria list, OL-164
SecuRemote connections
Selection Criteria Manager, WI-225, OL-157,
encapsulating, VP-55
SecuRemote daemon OL-166
description of, VP-104 Selection Criteria window, WI-225
SecuRemote kernel module sendmail.exe file, AA-377
description of, VP-103 server
SecuRemote user logical, WI-61
defining more than one encryption scheme server load
for, VP-78, VP-81 load balancing algorithm, AA-236
defining properties of, VP-77 server object
LEGEND
FireWall-1
Index-xxii FireWall-1 User Guide Master Index • September 1998

adding a server to a group, WI-108 Show All, AM-25
creating, WI-95 Show Null Matches option, OL-164
creating groups of server objects, WI-107, OL-81 shutdown command, GS-68
defining, WI-93, WI-94 Single Sign On System Extension, AA-98
deleting, WI-96 Single SignOn
deleting a server from a group, WI-109 SecuRemote, VP-125
modifying, WI-96 size limit, AM-31
SERVER_TIMEOUT, WI-6 SKIP
serverkeys file, AA-378 clock synchronization, VP-132
servers rekey policy mismatch, WI-148, OL-114, VP-39
logical, OL-25 restrictions on using with High Availability, AA-233
ServerTimeout, WI-6 specifying the encrypting gateway’s IP
service address, WI-21, OL-31, VP-25
restoring access to, blocked, AA-336 SKIP key
which available on network?, AA-353 changing, OL-121, VP-38
service object slapd.conf
creating new, WI-82 modifying, AM-25
defining, WI-81, OL-63 slapd.conf file, AA-379
deleting, WI-83, OL-65 slapd.pid file, AA-384
modifying, WI-83 SLIP, AA-365
Service Properties window, WI-91, OL-65 SMTP
service properties, generic, OL-73 badly formed header, WI-123, OL-95
service properties, RPC, OL-70 pipe, WI-123, OL-95
service properties, UDP, OL-68 source routing, WI-124, OL-95
Service Selection Criteria window, WI-235 SMTP resource
services CVP inspection, WI-127
dependence on other services, AA-354 restricting message size, WI-127, OL-97
which have more than one type, AA-353 SMTP Security Server, AA-109, AA-361
Services Manager, WI-82, OL-64 configuration file, AA-111
displaying, WI-8 supported protocols, AA-110
Services Manager window, OL-20 smtp service, AA-392
Session Authentication smtp.conf file, AA-379, WI-124, OL-98
configuring, AA-67 smtp.conf.org file, AA-379
overview, AA-66 smtp_rfc822 property, WI-123, OL-95
Session Authentication Agent SNMP, WI-46, OL-45
required for Session Authentication, AA-29 FireWall-1 daemon, GS-11
Session Authentication agent FireWall-1 MIB, AA-382
configuring, AA-69 trap, AA-284
pre-configuring, AA-70 snmp, AA-395
session hijacking, AA-363 SNMP daemon
preventing, AA-363 FireWall-1, AA-241
Session Key, VP-24 FireWall-1 MIB, AA-382
setup.C file, AA-381, WI-100, OL-79 inital keys, AA-242
Show, WI-238 initial communities, AA-242
LEGEND
FireWall-1
Master Index Index-xxiii

optional, AA-241 Static Source mode, AA-162
read and write communities (keys), AA-242 status
snmp file, AA-381 of FireWalled hosts, displaying, AA-264
snmp service, AA-395 of hosts, displaying using command-line
SNMP Trap Alert Command, WI-147 interface, AA-264
SNMP Trap Alert command, WI-147, OL-113 status display
SNMP traps, AA-242 updating and changing, WI-204, OL-147
snmp.C file, AA-242, AA-379 status_alert, AA-284
snmp.def file, AA-381 status_alert file, AA-377
snmp_trap, AA-284 std.def file, AA-381
snmp_trap file, AA-377 stderr
snmpd file, AA-377 rsh/rexec reverse stderr connections, AA-391,
snmp-trap, AA-395 WI-146
stdin
SOFTWARE\CheckPoint\FireWall-1 GUI, WI-6
message describing alert available in, OL-114
sounds like operator, AM-33
Steelhead, see Microsoft RRAS
Source Object Selection Criteria window, WI-228
StreamWorks, AA-395
source port range, WI-84, WI-86, OL-66, OL-68
suggested reading, GS-26
source-quench, AA-398
SunNetManager, AA-382
Specific Sign-on, AA-82
suspected intruders
SPI
blocking connections to and from, WI-215
defining, VP-66
switch
using, VP-65
defining network object as, OL-33
spoof tracking, GS-99
definition of, GS-74
spoofing, GS-99, AA-338, WI-25, OL-35 setup, WI-49
SQLNet, AA-392 Xylan, WI-49, OL-48, OL-49
sqlnet2, AA-322
Sybase SQL, AA-392
and Address Translation, AA-171 synch, AA-303
Src Routing, WI-43 synchronization
SrcSpoofing (3Com) , WI-43 timing issues, AA-232
SSL, AA-366, AM-1, AM-3, AM-25 synchronized FireWall Modules
default, AM-18 restrictions on implementation, AA-232
negotiating parameters for, AM-20 synchronized FireWalls
port number for LDAP connection, WI-106 resources, AA-233
SSL connections, WI-106 restrictions, AA-232
SSL fingerprint synchronizing FireWall Modules
confirming with the LDAP Server’s system on different platforms, AA-232
administrator, AM-20 SYNDefender, OL-116
Standard Sign-on, AA-82 guidelines for choosing between methods, AA-333
Standard.W file, AA-379 when changes to Maximum Sessions take
starts with operator, AM-33 effect, WI-150
state directory, AA-384 SYNDefender Gateway
state tables description of, AA-331
cleared when Security Policy re-installed, AA-345 SYNDefender Passive Gateway
Static Destination mode, AA-164 description of, AA-333
LEGEND
FireWall-1
Index-xxiv FireWall-1 User Guide Master Index • September 1998

syntax differences deleting, AM-58
NT and Unix, AA-253 effect of modifications to on attached users, AM-58
syslog, AA-395, WI-45, OL-44 user, OL-57
syslogd, WI-45, OL-44 tftp, AA-395
System Status time object
displaying, WI-8 creating, WI-136
system status creating groups of time objects, WI-139, OL-106
changing and updating display of, WI-204, defining, WI-135, OL-103
OL-147 deleting, WI-136
monitoring, GS-128 editing existing, WI-136
System Status View window, GS-128 groups, WI-139
System Status window, GS-11, WI-202, OL-146 modifying, WI-136
properties, WI-135
T time object group
table.def file, AA-381 deleting from, WI-140
tables time service, AA-392, AA-396
synchronizing, AA-303 Time Stamping, WI-43
TACACS, AA-30, AA-273, AA-395, AM-48 time-exeeded, AA-398
TACACS authentication connection, AA-274 timeout, OL-69, OL-71
TACACS Server caused by delay of entering user name and
enabling connections from FireWall Module password, VP-93
to, WI-143, OL-109 connection to Management Server, WI-6
TACACS servers timeout parameter
defining, WI-100 smtp.conf, AA-111
TACACS+, AA-392 timestamp, AA-383, AA-398
Talk protocol, AA-365 timestamp reply, AA-398
TCP timestamp request, AA-398
service properties, WI-83
TimeStep, WI-55
TCP connections
setup, WI-55
established, AA-322
TimeStep Integrated FireWall
TCP sequence number prediction, AA-363
setup, WI-55
TCP Session Timeout, WI-143, OL-109 timing issues
TCP sessions synchronization, AA-232
established, AA-322 Tiny Fragments, WI-43
TCP Stacks
tmp directory, AA-384
supported by SecuRemote, VP-93
tod, AA-309
tcpip.def file, AA-381
topology download, VP-83, VP-112
TELNET
traceroute, AA-396
FireWall-1 daemon, AA-356
transitional links option, GS-56
User Authentication, GS-18, AA-29
Transparent Authentication, AA-28
telnet, AA-392
trap
TELNET daemon, AA-356
SNMP, AA-284
template
TRAP macro, AA-316
changing, AM-58
trapexec.conf file, AA-379
creating, AM-57
LEGEND
FireWall-1
Master Index Index-xxv

traps.def file , AA-381 URL Filtering, AA-130
traps.h file, AA-381 URL filtering
tree object step by step procedure, AA-130
creating in LDAP directory, AM-24 user
troubleshooting changing the template to which a user is
installation, VP-142 attached, AM-44
no SecuRemote Server along route, VP-143 defining new, AM-44
routing, VP-143 deleting, AM-45
truncated fields generic, AA-325, WI-72, OL-61
when printing a log, AA-340 group, defining properties of, WI-73
tty warning, AA-341 modifying, AM-44
two or more FireWalls restricting internal user’s access to JAVA
going across for authenticated services, AA-359 applets, WI-123
Type Selection Criteria window, WI-230 User Authentication
authentication rule, WI-175, OL-134
U defining on a per-user rather than a per-group
UDP basis, AA-357
enabling replies, WI-143, OL-110 deployment, AA-32
service properties, WI-85, OL-68 description of, GS-98
UDP Replies, OL-110 GUI interface, AA-41
UDP response, WI-45, OL-44 overview, AA-31
UFP Server tracking and timeout parameters, AA-36
step by step procedure for using, AA-131 User Authentication Alert Command, WI-147,
UFP server, OL-77 OL-114
UFP Servers, WI-96, OL-77 User Database
UFP servers downloading, AA-264, WI-64, WI-79, OL-56
defining, WI-96 exporting, AA-285
uninstalling importing, AA-285
router access list, OL-142 installing, see User Database, downloading
uninstalling a Security Policy, AA-259 when changes take effect, WI-78, OL-61, OL-138
uninstalling SecuRemote, VP-108 User Defined Alert Command, WI-147, OL-113
uninstalling the Account Management Client, AM-13 user group
Unix and NT syntax differences, AA-253 adding to source of rule, WI-162
Unix platforms in rule, WI-162
minimum requirements, GS-55 restricting access based on, WI-162
Unknown Network Objects , WI-199, OL-140 User Password
upgrading restrictions, VP-93
FireWall-1 loses its state after, GS-35 user properties, WI-66, OL-58
objects carried over from previous version, GS-34 user.def file, AA-381
reinstalling Security Policy after, AA-345 userc.c file
to the current version from earlier versions, GS-34 installing standard version of, VP-82, VP-83,
what objects are carried over from previous VP-106, VP-111
version, AA-344 User-Defined Service Properties
URI Specification File Example, WI-89, OL-74
format, WI-121, OL-94 users
LEGEND
FireWall-1
Index-xxvi FireWall-1 User Guide Master Index • September 1998

defining in both LDAP and FireWall-1, AA-142, W
AA-154 WAIS, OL-68
exporting from FireWall-1 database to LDAP wais, AA-392
directory, AA-152 WebTheatre, AA-322, AA-393
restricting internal user’s access to JAVA Wellfleet
applets, WI-123, OL-87 managing Access Lists, AA-280
Users Manager Wellfleet See Bay Networks
displaying, WI-8 Wellfleet, see Bay Networks
Users Manager window, OL-20 wellfleet.C file, AA-381, AA-385
Uses H.323, AA-390 wellfleet.mib file , AA-382, AA-385
utilities, OL-143 who service, AA-396
utilities, additional, OL-149 Width window, WI-220
uucp, AA-392 Windows NT
monitoring performance, AA-405
V Windows Registry, AA-372
Valid Addresses, WI-25 FireWall-1 entries, AA-401
value of data field WinFrame, AA-393
modifying, OL-130 workstation objects
VDO-Live, AA-392 listing in hosts and lmhosts files, WI-22, WI-36,
enabling back connections, AA-392 OL-28, OL-38
VDOLive, AA-322, AA-325, WI-85, OL-67 www.opsec.com, AA-120
using with SecuRemote Client, VP-92
version X
specifying the FireWall-1 version, WI-23 X.25, AA-365
version 3.0 and earlier X/Motif
compatibility with Version 4.0, GS-34 obtaining a license for, GS-69
version 4.0 starting the GUI, GS-88, WI-4
compatibility with earlier versions, GS-34 starting the Log Viewer, WI-212
version number starting the System Status View, WI-202
displaying, AA-267 where to install license, GS-69
View menu, WI-178 X/Motif libraries
viewing version used by FireWall-1, GS-59, GS-68
Inspection Script, WI-194, OL-137 X11, AA-393
log, WI-211, OL-151 Xing, AA-395
VIRSIG.DAT file, AA-377 and Address Translation, AA-171
Virtual Encryption Session, VP-23 xlate.conf file, AA-379
virtual interfaces, AA-363 Xlated Destination Port Selection Criteria
Virtual Link encryption features, WI-59, OL-52 window, WI-230
virtual packet reassembly, AA-363 Xlated Dst Selection Criteria window, WI-229
Vosaic, AA-392 Xlated Source Port Selection Criteria window , WI-230
VPN-1 Module, GS-81 Xlated Src Selection Criteria window, WI-229
VPN-1 Secure Center xtreme.def file, AA-381
configuration, AM-4 XView
VPN-1 SecuRemote/n, GS-81 limitation on number of menu objects, OL-32
LEGEND
FireWall-1
Master Index Index-xxvii

Xylan, GS-74, GS-77, GS-97
installing Encryption Module on, GS-77
Xylan switch
defining network object as, OL-33
setup, WI-49, OL-48, OL-49
Y
ypbind, AA-397
yppasswd, AA-397
ypserv, AA-397
ypupdated, AA-397
ypxfrd, AA-397
LEGEND
FireWall-1
Index-xxviii FireWall-1 User Guide Master Index • September 1998

FWVPN

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

FWVPN

Încărcat de

Drepturi de autor:

Formate disponibile

Virtual Private Networking

with Check Point

Part No.: 71300007400

Check Point Software Technologies Ltd.

e-mail: info@CheckPoint.com http://www.checkpoint.com

Please direct all comments regarding this publication to techwriters@checkpoint.com.

Scope xiii Encryption Schemes 5

Summary of Contents xiv Encryption Schemes Supported by

Configuration Examples 17 3. Encryption Properties 35

Specifying Encryption 17 Encryption Properties 35

A Two Gateway Configuration (FWZ) 17 Properties Setup - Encryption 36

Adding an Encryption Rule to a Rule SecuRemote 36

Both Gateways FireWalled 26 Encryption Setup 41

▼ Actions Performed by Alice 33 Encryption Setup — Manual IPSec 51

▼ Actions Performed by Bob 33 Encryption Setup — FWZ 52

ii Virtual Private Networking with FireWall-1 • September 1998

5. SecuRemote Client 103 Encryption Method 116

SecuRemote Client 103 Authentication Methods 117

SecuRemote Kernel Module 103 FWZ 117

iv Virtual Private Networking with FireWall-1 • September 1998

Closing the SecuRemote Daemon 125 Errors Reported by Bob (Decrypting

Help Menu 129 Master Index Index-i

viii Virtual Private Networking with FireWall-1 • September 1998

FIGURE 5-10 Site List 114

FIGURE 5-11 Site window 115

FIGURE 5-12 SecuRemote Client User Authentication

FIGURE 5-13 Password window 118

FIGURE 5-14 SecuRemote Client User Authentication

FIGURE 5-15 Certificate window (User and CA

FIGURE 5-16 Options window 120

FIGURE 5-17 Configure Entrust.INI window 122

FIGURE 5-18 Create User window 123

FIGURE 5-19 Recover User window 124

FIGURE 5-20 Properties menu 124

FIGURE 5-21 Configure Single SignOn

FIGURE 5-22 Single SignOn Enabled window 126

FIGURE 5-23 Disabling Single SignOn

FIGURE 5-24 SecuRemote Client Toolbar 130

FIGURE 6-1 Network Configuration for

TABLE P-1 Typographic Conventions xv TABLE 5-2 Encryption Method

TABLE 6-5 Default path for userc.c 145

xii Virtual Private Networking with FireWall-1 • September 1998

Getting Started with FireWall-1

Managing FireWall-1 Using the OpenLook GUI

Managing FireWall-1 Using the Windows GUI

FireWall-1 Architecture and Administration

This book is the technical reference to FireWall-1 features, including authentication

Virtual Private Networking with FireWall-1

Who Should Use this User Guide

It assumes you have a basic understanding and a working knowledge of:

Chapter 2, “Configuring FireWall-1 Encryption,” decribes how to configure FireWall-1

Chapter 3, “Encryption Properties,” is a reference to those parts of the FireWall-1

Chapter 4, “SecuRemote Server,” describes the FireWall-1 SecuRemote Server.

Chapter 5, “SecuRemote Client,” describes the SecuRemote Client.

Chapter 6, “Troubleshooting,” describes common problems and their solutions.

xiv Virtual Private Networking with FireWall-1 • September 1998

TABLE P-1 Typographic Conventions

AaBbCc123 The names of commands, files, Edit your .login file.

AaBbCc123 What you type, contrasted with machine_name% su

AaBbCc123 Book titles, new words or Read Chapter 6 in User’s Guide.

Shell Prompts in Command Examples

TABLE P-2 Shell Prompts

C shell prompt machine_name%