Check Firewall-1 Guide

8/3/2019 Check Firewall-1 Guide

1/272

Check Point FireWall-1

Guide

NG

Part No.: 700265

June 2001


2/272

2000-2001 Check Point Software Technologies Ltd.

All rights reserved. This product and related documentation are protected by copyrightand distributed under licensing restricting their use, copying, distribution, anddecompilation. No part of this product or related documentation may be reproduced inany form or by any means without prior written authorization of Check Point. Whileevery precaution has been taken in the preparation of this book, Check Point assumesno responsibility for errors or omissions. This publication and features described hereinare subject to change without notice.

RESTRICTED RIGHTS LEGEND:

Use, duplication, or disclosure by the government is subject to restrictions as set forthin subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clauseat DFARS 252.227-7013 and FAR 52.227-19.

TRADEMARKS:

Check Point, the Check Point logo, FireWall-1, FireWall-1 SecureServer, FloodGate-1,INSPECT, IQ Engine, MetaInfo, Meta IP, Open Security Extension, OPSEC, Provider-1,SecureKnowledge, SiteManager, SVN, UAM, UserAuthority, VPN-1, VPN-1 AcceleratorCard, VPN-1 Appliance, VPN-1 Certificate Manager, VPN-1 Gateway, VPN-1

SecureClient, VPN-1 SecuRemote, VPN-1 SecureServer and ConnectControl aretrademarks or registered trademarks of Check Point Software Technologies Ltd. or itsaffiliates. All other product names mentioned herein are trademarks or registeredtrademarks of their respective owners.

The products described in this document are protected by U.S. Patent No. 5,606,668and 5,835,726 and may be protected by other U.S. Patents, foreign patents, or pendingapplications.

THIRD PARTIES:

Entrust is a registered trademark of Entrust Technologies, Inc. in the United States andother countries. Entrusts logos and Entrust product and service names are alsotrademarks of Entrust Technologies, Inc. Entrust Technologies Limited is a wholly

owned subsidiary of Entrust Technologies, Inc. FireWall-1 and SecuRemote incorporatecertificate management technology from Entrust.

Verisign is a trademark of Verisign Inc.

The following statements refer to those portions of the software copyrighted byUniversity of Michigan.

Portions of the software copyright1992-1996 Regents of the University of Michigan.All rights reserved. Redistribution and use in source and binary forms are permittedprovided that this notice is preserved and that due credit is given to the University ofMichigan at Ann Arbor. The name of the University may not be used to endorse orpromote products derived from this software without specific prior written permission.This software is provided as is without express or implied warranty.

CopyrightSax Software (terminal emulation only).The following statements refer to those portions of the software copyrighted byCarnegie Mellon University.

Copyright 1997 by Carnegie Mellon University. All Rights Reserved.

Permission to use, copy, modify, and distribute this software and its documentation forany purpose and without fee is hereby granted, provided that the above copyright noticeappear in all copies and that both that copyright notice and this permission notice

appear in supporting documentation, and that the name of CMU not be used inadvertising or publicity pertaining to distribution of the software without specific, writtenprior permission.

CMU DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, INNO EVENT SHALL CMU BE LIABLE FOR ANY SPECIAL, INDIRECT ORCONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTINGFROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF

CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF ORIN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

The following statements refer to those portions of the software copyrighted byThe Open Group.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE ANDNONINFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FORANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OFCONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTIONWITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

The following statements refer to those portions of the software copyrighted byThe OpenSSL Project.

This product includes software developed by the OpenSSL Project for use in theOpenSSL Toolkit (http://www.openssl.org/).*

THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY *EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THEIMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULARPURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT ORITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOTLIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OFUSE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSEDAND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT

OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OFSUCH DAMAGE.

The following statements refer to those portions of the software copyrighted byEric Young.

THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND ANY EXPRESS ORIMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULARPURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR ORCONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY

THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THEUSE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCHDAMAGE.

Copyright1998The Open Group.

July

12,

2001

Check Point Software Technologies Ltd.

Please direct all comments regarding this publication to [email protected].

International Headquarters:

3A Jabotinsky Street

Ramat Gan 52520, Israel

Tel: 972-3-753 4555

Fax: 972-3-575 9256

U.S. Headquarters:

Three Lagoon Drive, Suite 400

Redwood City, CA 94065

Tel: 800-429-4391; (650) 628-2000

Fax: (650) 654-4233

e-mail: [email protected] http://www.checkpoint.com


3/272

Contents 3

Contents

Preface 13

Who Should Use this User Guide 13

Summary of Contents 13

Check Point Documentation 14

What Typographic Changes Mean 15

Shell Prompts in Command Examples 17

Network Topology Examples 17

1. Network Address Translation (NAT) 19

Introduction 19

The Need for Address Translation 19

Example 21

Configuring Network Address Translation 21

Address Translation Modes 22

Hide Mode 23

Statically Translating Addresses 26

Address Translation and Routing 29

Configuring Routing on the Gateway 29

IANA Recommendations 36

Supported Services 36

Restrictions 36

FTP port command 37

Generating Address Translation RulesAutomatically 37

Overview 37

Network Address Translation Rule Base 39

Overview 39

Structure of a NAT Rule 40

NAT Rule Base Example 41

Defining Address Translation Rules 43

Using the NAT Rule Base Editor 44

Address Translation Examples 52

Gateway with Two Interfaces 52

Gateway with Three Interfaces 55

Advanced Topics 59

Address Translation and Anti-Spoofing 59

Rule Base 65

Frequently Asked Questions 65

2. Authentication 71

Overview 71

VPN-1/FireWall-1 Authentication 71

Three Types of Authentication 72

User Authentication 74

User Authentication Overview 74

User Authentication Deployment 75

Non-Transparent User Authentication 88

User Authentication and the HTTP Security Server -

91

Session Authentication 109

Session Authentication Overview 109

Session Authentication Deployment 111


4/272

4 FireWall-1 Administration Guide June 2001

Client Authentication 120

Client Authentication Overview 120

Client Authentication Deployment 124

Single Sign On Additional Features 136

Client Authentication Examples of Sign OnMethods 139

Encrypted Client Authentication 147

Client Authentication SecurityConsiderations 147

Client Authentication Additional Features 148

3. Active Network Management 151

VPN-1/FireWall-1 State Synchronization 151

Implementation 152

Timing Issues 154

Restrictions 154

Troubleshooting 156

ConnectControl Server Load Balancing 156

The Need for Server Load Balancing 156

How Server Load Balancing Works 157

Load Balancing Algorithms 159

Logical Servers 159

Rule Base 161

Load Measuring 162Connection Accounting 162

Active Connections 162

4. Security Servers and Content

Security 163

Security Servers 163

Overview 163

Security Servers and the Rule Base 166

Interaction with OPSEC Products 178

Defining Security Servers 180

Security Server Configuration 184

Content Security 186

Resources and Security Servers 187

Web (HTTP) 189Mail (SMTP) 192

FTP 192

CVP Inspection 193

CVP Load Sharing and Chaining 194

5. Check Point High Availability 197

High Availability 197

Overview 197

Switch Support 199

When Does a Failover Occur? 199

Before Configuring High Availability 200

Installation 201

Upgrading Check Point High AvailabilityClusters 202

Configuration - All Platforms 204

Synchronization 209

Using High Availability in Virtual PrivateNetworks 209

Commands 211

Additional Configuration Parameters 216

6. Intrusion Detection 219

Overview 219

Malicious Activity Detection (MAD) 219

Attacks 220

Recognized Attacks 220

Configuration 221

MAD Configuration File 221

Installation 224

Enabling and Disabling MAD 224

Communication with VPN-1/FireWall-1 225

Troubleshooting 225Error Messages 225

7. SNMP and Network ManagementTools 227

Overview 227

VPN-1/FireWall-1 SNMP Agent (daemon) 227

FireWall-1 HP OpenView Extension 229

Installing the FireWall-1 HP OpenViewExtension 230


5/272

Contents 5

w To install the VPN-1/FireWall-1 HP OpenViewExtension (Solaris2) 230

w To install the VPN-1/FireWall-1 HP OpenView

Extension(HP-UX) 230

Uninstalling the VPN-1/FireWall-1 HP OpenViewExtension 231

w To uninstall the VPN-1/FireWall-1 HP OpenViewExtension (Solaris2) 231

w To uninstall the VPN-1/FireWall-1 HP OpenViewExtension (HP-UX) 232

Viewing FireWalled Objects 232

VPN-1/FireWall-1 MIB Source 234

8. FAQ (Frequently Asked Questions) 239

Defining Objects and Services 239

Daemons 243

Security Servers 243

Logging 247Security 248

SYNDefender 249

Guidelines for Deploying SYNDefender 256

Configuring SYNDefender 256

VPN-1/FireWall-1/n (VPN-1/FireWall-1/25,VPN-1/FireWall-1/50, etc.) Issues 257

Supported Protocols and Interfaces 258

Inspecting 260

Administrative Issues 261

Performance 261

Index Index-i


6/272



7/272


8/272


FIGURE 1-37 Rule Base both networks staticallytranslated 58

FIGURE 1-38 Multiple NAT Rules Added to

Automatically Generated Rules 59FIGURE 1-39 Address Translation and Anti-Spoofing

(Hide Mode) 61

FIGURE 1-40 Address translation and Anti-Spoofing(Static Source Mode) 62

FIGURE 1-41 Address translation and Anti-Spoofing(Static Destination Mode) 63

FIGURE 1-42 Address Translation and Anti-Spoofing(Example) 64

FIGURE 1-43 Hidden Internal Network 66

FIGURE 1-44 Invalid IP Addresses 69

FIGURE 2-1 User Properties window

Authentication tab 71

FIGURE 2-2 Example configuration 76

FIGURE 2-3 Example User Authentication Rule 76

FIGURE 2-4 User Properties window - Authenticationtab and Location tab 77

FIGURE 2-5 Group Properties window -LocalManagers group 77

FIGURE 2-6 Workstation Properties window Authentication page 78

FIGURE 2-7 Workstation Properties Authenticationpage UserAuthority Settings 81

FIGURE 2-8 Workstation Properties window Authentication page with User AuthoritySettings enabled 82

FIGURE 2-9 Network Objects window New Groupwith UserAuthority Server GroupSelected 83

FIGURE 2-10 User Authentication Action Propertieswindow 84

FIGURE 2-11 GUI FTP Authentication 87

FIGURE 2-12 NonTransparent UserAuthentication. 89

FIGURE 2-13 Global Properties window Authentication and Security Server

pages 92

FIGURE 2-14 Global Properties Window - HTTP ServerDefinition 93

FIGURE 2-15 Defining the gateway as the HTTP proxy

Netscape 4.7 97FIGURE 2-16 HTTPS Service Definition 99

FIGURE 2-17 A Typical User ID and PasswordWindow 100

FIGURE 2-18 Example HTTP Server definition 105

FIGURE 2-19 HTTP Servers behind a VPN/FireWallModule 107

FIGURE 2-20 HTTP Server Definition Server for NullRequests 108

FIGURE 2-21 Session Authentication 110

FIGURE 2-22 VPN-1/FireWall-1 Session AuthenticationAgent Prompt 110

FIGURE 2-23 Example configuration 111

FIGURE 2-24 Example Session Authentication

Rule 111

FIGURE 2-25 VPN-1/FireWall-1 Session Authenticationwindow 112

FIGURE 2-26 Configuration window Passwordstab 113

FIGURE 2-27 Configuration window AllowedFireWall-1 tab 114

FIGURE 2-28 Configuration window Optionstab 114

FIGURE 2-29 SETUP.INI file 115

FIGURE 2-30 SSL Configuration Tab SessionAuthentication Agent 117

FIGURE 2-31 Session Authentication ActionAuthentication Properties window 117

FIGURE 2-32 Session Authentication window userprompt 119

FIGURE 2-33 Session Authentication window password prompt 120

FIGURE 2-34 Example Client Authentication RuleBase 121

FIGURE 2-35 Example configuration ClientAuthentication 125

FIGURE 2-36 Example Client Authentication rule 125


9/272

Figures 9

FIGURE 2-37 User Properties window - Authenticationtab and Location tab 126

FIGURE 2-38 Group Properties window Defining

Permitted Users 126FIGURE 2-39 User Access window 127

FIGURE 2-40 Workstation Properties window Authentication page 128

FIGURE 2-41 Client Authentication Action Propertieswindow General tab 129

FIGURE 2-42 Client Authentication Action Properties

window

Limits tab131

FIGURE 2-43 Global Properties window Authentication page 133

FIGURE 2-44 Single Sign On Extension. 136

FIGURE 2-45 Client Authentication Rule 139

FIGURE 2-46 Client Authentication - Standard Sign Onfor all Services and Destinations AllowedUnder Rule 141

FIGURE 2-47 Client Authentication - Specific Sign Onfor two Services (Each One on a DifferentHost) 142

FIGURE 2-48 Client Authentication - Signing Off 143

FIGURE 2-49 HTTP session on port 900 143

FIGURE 2-50 VPN-1/FireWall-1 Session AuthenticationAgent prompt 145

FIGURE 2-51 Beginning an encrypted ClientAuthentication Session 147

FIGURE 2-52 $FWDIR/conf/fwauthd.conf

file 150

FIGURE 3-1 Two VPN/FireWall Modules inSynchronized Configuration 153

FIGURE 3-2 Load Balancing among several

servers 157

FIGURE 3-3 Logical Server Properties window 160

FIGURE 3-4 Using Logical Servers in a Rule 161

FIGURE 4-1 A connection handled by theVPN-1/FireWall-1 Inspection (Kernel)Module 164

FIGURE 4-2 Protected FTP Server 166

FIGURE 4-3 Network Rule Base 166

FIGURE 4-4 Sample Rule Base with user groups 167

FIGURE 4-5 Sample Rule Base employing a morepermissive rule 167

FIGURE 4-6 Authentication Procedure 168

FIGURE 4-7 VPN-1/FireWall-1 SMTP SecurityServer 171

FIGURE 4-8 Workstation PropertiesAdvanced tab SMTPpage 172

FIGURE 4-9 Proxy Configuration Netscape 4.7 andInternet Explorer 5.5 174

FIGURE 4-10 HTTP Proxy and Security Proxy Settings Netscape 4.0x and Internet Explorer3.0x 176

FIGURE 4-11 URI Definition window - ConnectionsMethods 177

FIGURE 4-12 Connection invoking a UFP Server 179

FIGURE 4-13 Global Properties window - SecurityServer page 180

FIGURE 4-14 Customized Security Server messagedefining host content as FW-1 182

FIGURE 4-15 Customized Security Server message withSecurity Server at as definedcontent 182

FIGURE 4-16 Customized Security Server message withProxy Authorization as defined

content 183

FIGURE 4-17 $FWDIR/conf/fwauthd.conf example 184

FIGURE 4-18 A connection mediated by the HTTPSecurity Server 187

FIGURE 4-19 Content Vectoring Server 188

FIGURE 4-20 URI Resource Definition 189

FIGURE 4-21 URI Definition window Match tab (UFPspecification) Defining Rules 190

FIGURE 4-22 Rule Base using Resources 191

FIGURE 4-23 URI Definition window - CVP tab 191

FIGURE 4-24 Three CVP Servers invoked one after theother. 195

FIGURE 5-1 High Availability configuration 198

FIGURE 5-2 Global Properties window - HighAvailability page 202


10/272


11/272

Tables 11

Tables

TABLE P-1 Typographic Conventions 15

TABLE P-2 Command-line UsageConventions 16

TABLE P-3 Shell Prompts 17

TABLE 1-1 Private Networks Address Space 36TABLE 1-2 Address Translation Service

Restrictions 36

TABLE 1-3 Condition vs. Translation 41

TABLE 1-4 Adding a Rule 44

TABLE 1-5 Original Packet - Source 45

TABLE 1-6 Original Packet - Destination 46

TABLE 1-7 Original Packet - Services 46

TABLE 1-8 Translated Packet - Source 47

TABLE 1-9 Translated Packet - Destination 49

TABLE 1-10 Install On Menu 50

TABLE 1-11 Copying, Cutting and PastingRules 51

TABLE 1-12 Address translation and Anti-Spoofing (Hide Mode) 61

TABLE 1-13 Address translation and Anti-Spoofing (Static Source Mode) 62

TABLE 1-14 Address translation and Anti-Spoofing (Static DestinationMode) 63

TABLE 2-1Comparison of AuthenticationTypes 73

TABLE 2-2 Meaning of No Activity 79

TABLE 2-3 Access Possibilities 85

TABLE 2-4 HTTP Security Server errormessages 101

TABLE 2-5 Browser Messages 102TABLE 2-6 HTTPS options 105

TABLE 2-7 Servers and URLs 107

TABLE 2-8 SSL options 116

TABLE 3-1 Explanation of Rule Base 161

TABLE 4-1 VPN-1/FireWall-1 Security Servers features 165

TABLE 4-2 FTP actions and commands 169

TABLE 4-3 SMTP field meanings 173

TABLE 4-4 Security Server message fields 181

TABLE 4-5 $FWDIR/conf/fwauthd.conffields 184

TABLE 4-6 Security Service binaries 184

TABLE 5-1 High Availability Data 210

TABLE 6-1 Attack Names and Descriptions220

TABLE 6-2 Global Parameters 222

TABLE 6-3 Attack-Specific Parameters 222

TABLE 6-4 NetQuota/ServerQuotaParameters 224

TABLE 6-5 MAD Exit Error Messages 225


12/272


TABLE 7-1 VPN-1/FireWall-1 MIB Variables 229

TABLE 7-2 Minimum Requirements 230

TABLE 7-3 FireWall Menu Commands 233

TABLE 8-1 Services available under both TCP andUDP 240

TABLE 8-3 Services Dependent on Other

Services 241

TABLE 8-2 Services available both as RPC andTCP or UDP 241


13/272

13

Preface

Who Should Use this User Guide

This User Guide is written for system administrators who are responsible for

maintaining network security. It assumes you have a basic understanding and a

working knowledge of:s system administration

s the Unix or Windows operating system

s the Windows GUI

s Internet protocols (IP, TCP, UDPetc.)

Summary of Contents

Chapter 1, Network Address Translation (NAT), describes VPN-1/FireWall-1sNetwork Address Translation feature.

Chapter 2, Authentication, describes VPN-1/FireWall-1s Authentication features.

Chapter 3, Active Network Management, describes VPN-1/FireWall-1s Active

Network Management features, including ConnectControl and Connection Accounting.

Chapter 4, Security Servers and Content Security, describes how to implementcontent security using Check Point Security Servers.

Chapter 5, Check Point High Availability, describes High Availability (redundancy)

and Load Sharing features for VPN/FIreWall Modules.

Chapter 6, Intrusion Detection, describes how to configure VPN-1/FireWall-1 to

detect intrusion attempts.

Chapter 7, SNMP and Network Management Tools, describes how VPN-1/FireWall-1

interfaces to network management tools.


14/272


Chapter 8, FAQ (Frequently Asked Questions), is a compilation of Frequently Asked

Questions about VPN-1/FireWall-1.

Check Point DocumentationUser Guides are available for each product in Portable Document Format (PDF) in the

Check Point Enterprise Suite. The Adobe Acrobat Reader is required to view PDF files

and is also available on the Check Point Enterprise Suite CD-ROM. Alternatively, youcan download the Acrobat Reader from the Adobe Web site (http://www.adobe.com).

The following User Guides are available for Check Point Enterprise Suite products.

1 Check Point Getting Started Guide This book is an introduction to Check Pointproducts.

2 Check Point Management Guide This book describes the Check Point

Management GUI, which is used to manage VPN-1/FireWall-1 and other CheckPoint products.

3 Check Point FireWall-1 Guide This book describes Check Point VPN-1/

FireWall-1.

4 Check Point Virtual Private Networks Guide This book describes Check PointVPN-1/FireWall-1s encryption features, and the Check Point desktop clients:

SecuRemote and SecureClient

5 Check Point FloodGate-1 Guide This book describes Check Point FloodGate-1,

which enables administrators to manage the quality of service on their networks.

6 Check Point Real Time Monitor Guide This book describes the Check Point Real

Time Monitor, which enables administrators to monitor quality of service on their

network links, as well as Service Level Agreement compliance.

7 Check Point Provider-1 Guide This book describes Check Point Provider-1,

which enables service providers and managers of large networks to provideCheck Point products-based services to large numbers of subscribers.

8 Check Point Reference Guide This book is a reference guide to Check Pointcommands.

9 Check Point Reporting Module Guide This book describes the Check PointReporting Module, which enables administrators to manage databases of Check

Point log-based information.

10 Check Point UserAuthority Guide This book describes Check Point

UserAuthority, which enables third-party and Web applications to leverage Check

Points sophisticated authentication and authorization technologies.

11 Check Point User Management Guide This book describes Check Point

LDAP-based user management.


15/272

Preface 15

12 Check Point MetaIP User Guide This book is the reference guide to Check

Point MetaIP, which enables administrators to manage IP address allocation onlarge networks.

13 Check Point Master Index This book is a master index to all Check Point UserGuides.

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,

and directories; on-screen

computer output

Edit your.login file.

Use ls -a to list all files.

machine_name% You have mail.

AaBbCc123 What you type, whencontrasted with on-screen

computer output

machine_name% suPassword:

AaBbCc123 Command-line placeholder:

replace with a real name or

value

To delete a file, type rmfilename.

AaBbCc123 Book titles, new words or

terms, or words to be

emphasized

Read Chapter 6 in Users Guide.These are called class options.

You must be root to do this.

Save Text that appears on anobject in a window

Click the Save button.


16/272


17/272

Preface 17

Shell Prompts in Command Examples

The following table shows the default system prompt and superuser prompt for the Cshell, Bourne shell, Korn shell and DOS.

Network Topology Examples

Network topology examples usually show a gateways name as a city name (forexample, Paris or London) and the names of hosts behind each gateway as names ofpopular sites in those cities (for example, Eiffel and BigBen).

TABLE P-3 Shell Prompts

Shell Prompt

C shell prompt machine_name%

C shell superuser prompt machine_name#

Bourne shell and Korn shellprompt

$

Bourne shell and Korn shellsuperuser prompt

#

DOS current-directory>


18/272



19/272

19

CHAPTER 1

Network AddressTranslation (NAT)

In This Chapter

Introduction

The Need for Address TranslationThe need for IP address translationreplacing one IP address in a packet by anotherIP addressarises in two cases:

1 The network administrator wishes to conceal the networks internal IP addressesfrom the Internet.

The administrator may reason that there is nothing to be gained, from a securitypoint of view, by making a networks internal addresses public knowledge.

Introduction page 19

Configuring Network Address Translation page 21Address Translation Modes page 22

Address Translation and Routing page 29

IANA Recommendations page 36

Supported Services page 36

Generating Address Translation Rules Automatically page 37

Network Address Translation Rule Base page 39

Address Translation Examples page 52

Advanced Topics page 59

Advanced Topics page 59

Frequently Asked Questions page 65

Introduction


20/272

Introduction


2 An internal networks IP addresses are invalid Internet addresses (that is, as faras the Internet is concerned, these addresses belong to another network).

This situation may have arisen for historical reasons: an internal network was

originally not connected to the Internet and its IP addresses were chosen withoutregard to Internet conventions. If such a network is then connected to theInternet, its long-established internal IP addresses cannot be used externally.Changing these addresses may be impractical or unfeasible.

In both cases, the internal IP addresses cannot be used on the Internet. However,Internet access must still be provided for the internal hosts with the invalid or secretIP addresses.

Application gateways (proxies) have historically served as a partial solution to theseproblems. For example, to hide his or her internal IP addresses, a user can TELNET toa gateway and from there continue to the Internet through a proxy. VPN-1/FireWall-1can be easily set up to provide and enforce such a scheme for a wide variety ofservices (FTP, TELNET, HTTP, and almost all other TCP, UDP and RPC services).Moreover, VPN-1/FireWall-1 supplements this scheme by providing user authenticationon the gateway.

On the other hand, proxies have drawbacks:

s Proxies are tailored per application, so it is impossible to use applications thatare not proxied, inbound or outbound.

s Proxies are not transparent, so that even authorized outbound users need to gothrough the application on the gateway, and impose a large overhead on thegateway host. Once a connection is accepted by a proxy, it functions as a packetforwarder at the application layer, which is an inefficient use of resources.

s It is difficult to provide good proxies for protocols other than TCP.

In contrast, VPN-1/FireWall-1s generic and transparent fully RFC 1631 compliantAddress Translation feature provides a complete and efficient solution. Theadministrator can determine which internal addresses are to be hidden (that is,mapped to the FireWalled hosts IP address) and which are to be mapped to a range ofIP addresses visible to the Internet. At the same time, internal hosts can be configuredto be accessible from the Internet even though their internal IP addresses are invalidInternet addresses. VPN-1/FireWall-1 achieves full Internet connectivity for internalclients.

Address Translation can be used to implement one way routing, so that there is noroute from the outside to an internal network or to hosts.

Note Address Translation changes IP addresses in the packet, so it is almost alwaysnecessary to make some changes in the routing tables to ensure that packets withtranslated addresses reach their proper destinations.

Example


21/272

Example

Chapter 1 Network Address Translation (NAT) 21

Example

Consider the following network configuration:

FIGURE 1-1 Example Network Configuration

Suppose the administrator of this network wishes to provide mail services to theinternal (private) hosts, but the internal IP addresses cannot be used, for one of thereasons stated above (see The Need for Address Translation on page 19.)

One possible solution is to move the mail server (which is currently on one of theinternal hosts) to the gateway. This solution is not optimal, because of:

s the significant overhead the mail server imposes on the gateway

s reduced security

s the administrative overhead incurred when modifying the configuration

A better solution might be to implement Address Translation on the gateway, asfollows, using the Static Destination Mode of Address Translation (see Static

Destination Mode on page 28):s The mail server is assigned a valid IP address (its public IP address), which is

exposed to the Internet. However, internally, the mail server retains its existing(private) IP address.

s Incoming mail arrives at the gateway, where the destination IP address (the mailservers public IP address) is translated to its private address. The source IPaddress of outgoing mail is translated from the mail servers private IP address toits public IP address.

Routing tables on the gateway and router may have to be modified to implementthis scheme (see Address Translation and Routing on page 29).

Configuring Network Address Translation

To configure Network Address Translation (NAT), proceed as follows:

1 Determine which NAT Mode to use: Hide Mode or Static Mode.

See Address Translation Modes on page 22 for detailed information aboutthese modes.

Note The gateway has a valid IP address which cannot be hidden.

mailsrvrLondon

Router

FireWalledGatewaylocalnet

private public

Internet

Address Translation Modes


22/272


2 Define the NAT Rule Base.

There are two methods of defining NAT rules: automatic (the recommendedmethod) and manual.

s Automatic Definition The NAT rules are automatically generated, basedon the properties of network objects (workstations, networks and AddressRanges).

The objects properties are applied whenever the object is used in theSecurity Policy. In addition, numerous implementation details areautomatically handled correctly (for example, Anti-Spoofing). In contrast,when rules are defined manually, these implementation details must beimplemented manually as well.

Automatic definition is the simplest method to use, but it is inflexible: thegenerated rules cannot be modified, but you can add rules (with the secondmethodsee below) before and after the automatically generated rules.

For information on this method, see Generating Address Translation RulesAutomatically on page 37.

s Manual Definition

The NAT Rule Base is defined manually. You can also add NAT rules beforeand after the rules generated automatically by the previous method, butyou cannot modify or delete the automatically generated rules.

This method is not as simple to use as the previous method, but is morepowerful and more flexible.

3 Configure routing so that NAT packets are properly routed.

See Address Translation and Routing on page 29 for more information.

Address Translation ModesVPN-1/FireWall-1 supports two Address Translation Modes:

Dynamic (Hide) Many invalid addresses are translated to a single valid address, anddynamically assigned port numbers are used to distinguish between the invalidaddresses.

Dynamic Address Translation is called Hide Mode, because the invalid addressesare hidden behind the valid address. For details of this mode, see Hide

Mode on page 23.

Static Each invalid address is translated to a corresponding valid address.

There are two modes of Static Address Translation:

s Static Source Mode (see Static Source Mode on page 26)

s Static Destination Mode (see Static Destination Mode on page 28)

Hide Mode


23/272


In This Section

Hide Mode

Hide Mode is used for connections initiated by hosts in an internal network, where thehosts IP addresses are invalid. In Hide Mode, the invalid internal addresses arehidden behind a single valid external address, using dynamically assigned port

numbers to distinguish between them.

Assigning Port Numbers

Port numbers are dynamically assigned from two pools of numbers:

s from 600 to 1023

s from 10,000 to 60,000

If the original port number is less than 1024, then a port number is assigned from thefirst pool. If the original port number is greater than 1024, then a port number isassigned from the second pool. VPN-1/FireWall-1 keeps track of the port numbersassigned, so that the original port number is correctly restored for return packets. Aport number currently in use is not assigned again to a new connection.

Limitations

Hide Mode has several limitations:

s Hide Mode does not allow access to the hidden hosts to be initiated from theoutside, that is, an external machine cannot connect to any of the hosts whoseaddresses have been translated. For example, in the configuration in FIGURE 1-3on page 24, if you run your HTTP server on 200.0.0.108 (one of the internal

machines with an invalid address), external machines will not be able to connectto your HTTP server using 199.203.145.35 (the gateways valid address) as thedestination.

This limitation can also be considered an advantage of Hide Mode.

s Hide Mode cannot be used for protocols where the port number cannot bechanged.

s Hide Mode cannot be used when the external server must distinguish betweenclients on the basis of their IP addresses, since all clients share the same IPaddress under Hide Mode.

Hide Mode page 23

Static Source Mode page 26Static Destination Mode page 28

Note The IP address of a gateways external interface must neverbe hidden.



24/272


Example

Suppose localnet is an internal network with invalid addresses are as follows:

199.203.145.35 is the address of gateways external interface.

You can hide the invalid addresses behind the valid address by specifying AddressTranslation in the NAT tab of localnets Network Properties window as follows:

FIGURE 1-2 NAT tab for localnet

Source addresses of outbound packets from hosts in localnet will be translated to

199.203.145.35, as illustrated in FIGURE 1-3. The source port number serves to directreply packets to the correct host.

FIGURE 1-3 Hide Mode Address Translation

Valid IP address Invalid IP addresses199.203.145.35 200.0.0.100 - 200.0.0.200

Original Packet

Gateway

internalnetwork

localnet

Internet

AddressTranslation

address

port

source destination

200.0.0.104 192.233.145.35

1305 x

address

port

source destination

192.233.145.35199.203.145.35

199.203.145.35

199.203.145.35

2531 x

address

port

source destination

200.0.0.104192.233.145.35

1305x

address

port

internal

interfacesource destination

192.233.145.35

2531x

Reply Packet

external

interface

Hide Mode


25/272


The following two Address Translation rules (FIGURE 1-4) are automatically generatedfrom the above definition (FIGURE 1-2 on page 24):

FIGURE 1-4 Hide Mode Automatically Generated Rules

The first rule (which does not translate anything) applies to connections from thegateway to localnet and prevents the address of the gateways internal interface frombeing translated.

For an explanation of why this rule is necessary, see Can I translate thegateways internal address? on page 66.

The second rule expresses the Address Translation defined in the NAT tab (FIGURE 1-2on page 24) and illustrated in FIGURE 1-3. Note the small letterH underlocalnetsicon, which indicates Hide Mode translation.

For a detailed description of the meaning of the fields in an Address Translation RuleBase, see Structure of a NAT Rule on page 40.

Choosing the Valid External Address for Hide Mode

You can choose to hide the internal IP addresses either behind the IP address of thegateways external interface, or behind another IP address (that is, a valid IP addressthat does not belong to any of the gateways interfaces, but one which you can routeto the gateway).

If you hide the internal IP addresses behind the IP address of the gateways external interface ...

You will not have to make any changes to your routing tables (see AddressTranslation and Routing on page 29), because presumably the routing tables arealready correctly configured for the gateways external interface.

On the other hand, you may have problems when a hidden connection shadowsa connection originating on the gateway itself. For example, suppose a user onthe gateway TELNETs to an external server, and is allocated the local TCP port10001 by the gateways TCP module. Next, a user on one of the internal hostsalso TELNETs to the external server and, because the connection is hidden, it isallocated the same TCP port 10001 by the VPN/FireWall Module on the gateway.

Note Routing tables on the gateway and router may have to be modified to implementthis scheme (see Address Translation and Routing on page 29).


26/272

Statically Translating Addresses


27/272


Example

Suppose localnet is an internal network with invalid addresses, but a corresponding setof valid addresses is available, as follows:

You can translate the invalid addresses to the valid addresses by specifying AddressTranslation in the NAT tab of localnets Workstation Properties window as follows:

FIGURE 1-6 Static Address Translation

The invalid addresses of hosts in localnet will be translated to the valid addressesstarting at 199.203.73.15.

FIGURE 1-7 Address Translation using Static Source Mode

Valid IP addresses Invalid IP addresses

199.203.73.15 199.203.73.115 200.0.0.100200.0.0.200

Gateway

source destination

200.0.0.108 192.233.145.35

source destination

200.0.0.108192.233.145.35

internalnetwork

localnet

192.233.145.35

source destination

199.203.73.23

192.233.145.35

source destination

199.203.73.23

AddressTranslation

Original Packet

Reply Packet

Internet



28/272


The following three Address Translation rules (FIGURE 1-8) are automatically generatedfrom the above definition (FIGURE 1-6 on page 27):

FIGURE 1-8 Automatically Generated Address Translation rules for Static Translation

The first rule (which does not translate anything) applies to connections from thegateway to localnet and prevents the address of the gateways internal interface frombeing translated. For an explanation of why this rule is necessary, see Can I translatethe gateways internal address? on page 66.

Note that two static translation rules are generated:

s The first static translation rule (rule number 2) is a Static Source Mode rule, and

defines the Address Translation illustrated in FIGURE 1-7.s The second static translation rule (rule number 3) is the corresponding Static

Destination rule and defines the Address Translation illustrated in FIGURE 1-9 onpage 29 (see Static Destination Mode on page 28).

For a detailed description of the meaning of the fields in an Address Translation RuleBase, see Structure of a NAT Rule on page 40.

Static Destination Mode

Static Destination Mode translates valid addresses to invalid addresses for connectionsinitiated by external clients. Static Destination Mode is used when servers inside theinternal network have invalid IP addresses, and ensures that packets entering the

internal network arrive at their proper destinations. Static Destination Mode is usuallyused together with Static Source Mode.

When you generate Address Translation rules automatically, Static Source Mode andStatic Destination Mode rules are always generated in pairs.

Note Routing tables on the gateway and router may have to be modified to implementthis scheme (see Address Translation and Routing on page 29).

Configuring Routing on the Gateway


29/272


Example

Suppose localnet is an internal network with invalid addresses, but a corresponding setof valid addresses is available, as follows:

The second static translation rule (rule number 3) in FIGURE 1-8 on page 28 (generatedfrom the NAT tab in FIGURE 1-6 on page 27) translates the valid addresses starting at199.203.73.15 to the corresponding invalid addresses starting at 200.0.0.100. Thisis illustrated in FIGURE 1-9.

FIGURE 1-9 Address Translation using Static Destination Mode

Address Translation and Routing


To correctly implement Address Translation, you must ensure that a return packetintended for a host whose address has been translated is routed back to that host.

There are two routing issues involved:

s ensuring that the packet reaches the gateway

s ensuring that the gateway forwards the packet to the correct interface and host

Valid IP addresses Invalid IP addresses

199.203.73.15 199.203.73.115 200.0.0.100200.0.0.200

Note Routing tables on the gateway and router may have to be modified to implementthis scheme (see Address Translation and Routing below).

Note You will usually have to reconfigure your routing tables on the gateway (and on anyintervening routers) to implement Address Translation.

Gateway

source destination

200.0.0.113 192.233.145.35

source destination

200.0.0.113192.233.145.35

internalnetwork

localnet

192.233.145.35

source destination

199.203.73.28

192.233.145.35

source destination

199.203.73.28

Reply Packet

Original Packet

Internet



30/272


Ensuring That the Packet Reaches the Gateway

From the Inside

The internal hosts (whose addresses are being translated) need a default route to thegateway, just as they do without Address Translation.

From the Outside

The translated (valid) addresses must be published, so that replies will be routed backto the gateway.

However, a router positioned between the gateway and the Internet may fail to routereply packets to the translating gateway. Instead, the router sends ARP requests,

looking for the physical (MAC) address of the imaginary translated address.

For example, consider the network configuration below (FIGURE 1-10), where theinternal networks invalid addresses are hidden behind the non-existent IP address199.203.73.3 (see FIGURE 1-11 on page 31).

FIGURE 1-10 Hiding a Network

When the client (10.0.0.1) initiates a connection to the outside world, the gatewaytranslates the packets source address to 199.203.73.3, so when a reply packetarrives from the server, its destination address is 199.203.73.3. If no static routeexists, the router sees that the packet is destined for a directly attached network

router

FireWalledGateway

client10.0.0.1

le0 le110.0.0.8 199.203.73.1

internal network(illegal) 10.0.0.0

(netmask255.0.0.0)

Internet



31/272


(199.203.73.x) and sends an ARP request querying for the physical address (MAC) of199.203.73.3. But since 199.203.73.3 is an imaginary address, the router receivesno response for its query and drops the packet.

FIGURE 1-11 Hiding a network behind an imaginary IP address

There are three ways to solve this problem:

1 Reconfigure the Address Translation.

Hide the invalid network behind the gateways external address, as follows:

FIGURE 1-12 Hiding a network behind a real IP address

Note Starting with VPN-1/FireWall-1 Version NG, the Automatic ARP configurationproperty (Network Address Translation page of the Global Properties window see

NAT (Network Address Translation) on page 323 of Check Point Management Guide)solves this problem by automatically configuring the gateways ARP tables. See alsoAutomatic ARP Configuration Special Considerations on page 32.

Note In each case, you should stop and then restart the VPN/FireWall Module for thesechanges to take effect.

http://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdf


32/272


2 Another way of solving the problem is to change the routing on the router.

Define a static route on the router, using the equivalent of the Unix command:

3 A third way of solving the problem is to have the gateway respond to ARPrequests for the translated IP address (proxy ARP method).

Unix On the gateway, link the imaginary IP address (that is, the IP addressbehind which you are hiding the network) to the MAC address of the gatewaysexternal interface, using the arp command, as follows:

where is the non-existent IP address and is theexternal interfaces MAC address. For example,

NT Create a text file named local.arp in the $FWDIR\state directory. Each

line in the file should be of the form:

where is the non-existent IP address and (in theformat xx-xx-xx-xx-xx) is the external interfaces MAC address. For example,

Automatic ARP Configuration Special Considerations

When theAutomatic ARP configurationproperty (Network Address Translation page ofthe Global Properties windowsee NAT (Network Address Translation) onpage 323 ofCheck Point Management Guide) is enabled, the ARP tables on the VPN/

route add 199.203.73.3 199.203.73.1 1

Note Starting with VPN-1/FireWall-1 Version NG, the Automatic ARP configurationproperty (Network Address Translation page of the Global Properties window seeNAT (Network Address Translation) on page 323 of Check Point Management Guide)

automatically configures the gateways ARP tables, in the manner described here. See alsoAutomatic ARP Configuration Special Considerations on page 32.

arp -s pub

arp -s 199.203.73.3 00:a0:c9:45:b5:78 pub

199.203.73.3 00-a0-c9-45-b5-78

http://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdf


33/272


FireWall Module (gateway) performing NAT are automatically configured so that ARPrequests for a translated (NATed) machine, network or address range are answered bythe gateway.

Special care must be taken when configuring networks where this feature is used. Forexample, consider the configuration in FIGURE 1-13.

FIGURE 1-13 Automatic APRP configuration two gateways

Here two VPN/FireWall Modules (tower and bigben) on the same subnet areperforming NAT for clock (IP address 10.0.0.1hidden behind 2xx.1yy.1zz.80, alsoon the same subnet).

Suppose the following conditions are both true:

s Automatic ARP configuration is enabled (Network Address Translation page of theGlobal Properties window)

s NAT for clock is installed on All (NAT page of clocks Workstation Propertieswindow)

Then both tower and bigben will respond to ARP requests from the router, in otherwords, both tower and bigben will be pretending to be 2xx.1yy.1zz.80. There may alsobe OS messages warning about multiple nodes with the same IP address.

Note This kind of configuration (where two VPN/FireWall Modules are on the same

subnet) is generally not recommended, except in Load Sharing configurations.

internal network(illegal) 10.0.0.0

subnet 2xx.1yy.1zz.0

2xx.1yy.1zz.78

bigben

clock

tower

VPN/FireWallModule

2xx.1yy.1zz.79

VPN/FireWall

Module

10.0.0.1

Internetrouter



34/272


This problem can be avoided if the NAT for clock is installed only on one of thegateways (FIGURE 1-14).

FIGURE 1-14 Automatic ARP configuration installing NAT on only one gateway

Ensuring That the Gateway Forwards the Packet to the CorrectHost

When translating the destination address of a connection (Static Destination Mode),

packets may be forwarded to the wrong gateway interface if there are no static routeson the gateway to the translated (new) destination IP address.

IfPerform destination translation on the client side (Network Address Translation pageof the Global Properties windowsee NAT (Network Address Translation) onpage 323 ofCheck Point Management Guide) is not enabled, Address Translation takesplace in the gateway only after internal routing but before transmission (see AddressTranslation and Anti-Spoofing on page 59), so the gateways routing sees an externaldestination address. To ensure that these packets are correctly routed to an internal

host (and not bounced back out to the Internet), use static routing (the OS routecommand) to define the same next hop for both addresses.

Note This section applies only when Perform destination translation on the client sideis not enabled (Network Address Translation page of the Global Properties window).


F l id h f ll i fi i
http://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdfhttp://../FWSecAdmin/Props.pdf


35/272


For example, consider the following configuration:

FIGURE 1-15 Static Address Translation

FIGURE 1-16 Static Address Translation for mailsrvr

This results in the rules below (FIGURE 1-17):

FIGURE 1-17 Static Address Translation rules

The second rule will work correctly only if the gateway knows that in order to reach

the address 199.203.73.1, it should forward the packet to 10.0.0.1. To make thishappen, add a static route on the gateway, using the command:

route add 199.203.73.1 10.0.0.1 1

router

FireWalledGateway

internal network(invalid) 10.0.0.0

(netmask255.0.0.0)

mailsrvr10.0.0.1

le0 le1

10.0.0.8 199.203.73.241

Internet

IANA Recommendations

Th t l h t k th t th k t t th t l t d dd t b t d


36/272


The router also has to know that the packets to the translated address must be routedthrough the gateway. This can be achieved either by defining a static route on therouter, or by having the gateway publish (to the router) the fact it has a route to thetranslated address. For additional information about this problem, see Ensuring That

the Packet Reaches the Gateway on page 30.

IANA Recommendations

RFC 1918 documents private address spaces for organizations that will not have hostson the Internet.

The Internet Assigned Numbers Authority (IANA) has reserved the following threeblocks of the IP address space for private networks:

An enterprise that decides to use IP addresses in the address spaces defined above cando so without any coordination with IANA or an Internet registry. The address spacecan thus be used by many enterprises. Addresses within this private address space willonly be unique within the enterprise.

Supported Services

Restrictions

TABLE 1-2 lists restrictions that apply to Address Translation when used with protocolsthat carry IP addresses or port numbers in the packets data portion, as opposed to theIP or TCP or UDP header.

TABLE 1-2 lists these restrictions.

TABLE 1-1 Private Networks Address Space

class from IP address to IP address

A 10.0.0.0 10.255.255.255

B 172.16.0.0 172.31.255.255

C 192.168.0.0 192.168.255.255

TABLE 1-2 Address Translation Service Restrictions

Service Restrictions

sqlnet2 If the listener and server are on two different hosts whose IP addresses arebeing translated, then the difference between their untranslated IP addressesmust be the same as the difference between their translated IP addresses.For example, if their original IP addresses are 200.200.200.1 and200.200.200.11 (a difference of 10), then their translated IP addresses canbe 199.199.199.20 and 199.199.199.30 (also a difference of 10), but not199.199.199.20 and 199.199.199.40 (a difference of 20).

FTP port command

FTP port command


37/272


FTP port command

The FTP port command has been rewritten to support Address Translation, asspecified in RFC 1631.

Generating Address Translation Rules Automatically

Overview

You can generate NAT rules for machines, networks and Address Ranges automatically,using the NAT tab of the network objects Properties window (FIGURE 1-18 on page 38).

To generate Address Translation rules for a network object, proceed as follows:

1 Define the object whose address(es) will be translated using the Network ObjectManager.

For information on the Network Object Manager, see Chapter 4, NetworkObjects ofCheck Point Management Guide.

2 In the NAT tab of the objects Properties window, checkAdd Automatic AddressTranslation Rules.

When this box is checked, the other fields in the window are enabled.

Generating Address Translation Rules Automatically
http://../FWSecAdmin/NetObjs.pdfhttp://../FWSecAdmin/NetObjs.pdfhttp://../FWSecAdmin/NetObjs.pdfhttp://../FWSecAdmin/NetObjs.pdfhttp://../FWSecAdmin/NetObjs.pdfhttp://../FWSecAdmin/NetObjs.pdf


38/272


FIGURE 1-18 Automatic Address Translation for a Workstation

3 Select a Translation Method from the drop-down menu.

For information about translation methods, see Address Translation Modes onpage 22.

4 Enter an IP address for the translation.

If the Translation Method is Hide, then the IP address is the one behind whichthe objects addresses will be hidden (see Hide Mode on page 23).

If the Translation Method is Static, then the IP address is the first one in therange to which the objects addresses will be translated (see Statically

Translating Addresses on page 26).

5 In Install On, select a VPN/FireWall Module on which to install the generatedAddress Translation rule.

Overview

All means all VPN/FireWall Modules that are able to perform Address


39/272


/ pTranslation.

6 Click on OK or on Apply.

To view the NAT Rule Base (including the automatically generated rules), select theAddress Translation tab in the Rule Base Editor.

The automatically generated rules are colored differently from manually defined rules,

and are positioned first in the NAT Rule Base. Automatically generated rules cannot bemodified using the Rule Base Editor, nor can you change their sequence. Theautomatically generated rules themselves can only be modified by editing the fields inthe NAT tabs.

However, you can add rules before and after the automatically generated rules (seeNetwork Address Translation Rule Base on page 39). If you add rules before theautomatically generated rules and then add more automatically generated rules, thenew automatically generated rules will be positioned together with the other

automatically generated rules.

Network Address Translation Rule Base

Overview

Network Address Translation is defined in the form of a NAT Rule Base, where eachrule enables you to:

s specify objects by name rather than by IP address

s restrict rules to specified destination IP addresses, as well as to the specifiedsource IP Addresses

s

translate both source and destination IP addresses in the same packets restrict rules to specified services (ports)

s translate ports

Note It is best to select only the VPN/FireWall Modules that will actually be performing

the NAT for the object. For an example of when selecting All is incorrect, see AutomaticARP Configuration Special Considerations on page 32.

Note If a host for which Address Translation has been defined has more than one IPaddress (for example, if it is a gateway with multiple interfaces), the only IP address thatwill be translated is the IP address specified in the General tab of the WorkstationProperties window.


Structure of a NAT Rule


40/272


S

A NAT rule, like a Security Policy rule, consists of two elements:

s conditions that specify when the rule is to be applied

s the action to be taken when the rule is applied (that is, when the conditions aresatisfied)

The NAT Rule Base Editor (FIGURE 1-19) is divided into four sections:

s Original Packet

s Translated Packet

s Install On

s Comment

FIGURE 1-19 NAT Rule Base

Original Packet and Translated Packet consist of, in turn:

s Source

s Destination

s Service

Original Packet specifies the conditions, that is, when the rule is applied.

Translated Packet specifies the action to be taken when the rule is applied.

The action is always the same:

s translate Source underOriginal Packet to Source underTranslated Packet

s translate Destination underOriginal Packet to Destination underTranslatedPacket

s translate Service underOriginal Packet to Service underTranslated Packet

NAT Rule Base Example

If an entry underTranslated Packet is Original, then the corresponding entry under


41/272


Original Packet is not translated. TABLE 1-3 presents the various possibilities, usingService as an example.

NAT Rule Base Example

FIGURE 1-20 shows an example of a manually-defined NAT Rule Base.

FIGURE 1-20 Manually-defined NAT Rule Base

Rule 1

The first rule in FIGURE 1-20 (a Hide Mode rule note the small letterH undernatashas icon) specifies that:

Condition when the original packets Source address belongs to the networkobject MyNetwork

Action hide its Source address behind the address of the network objectnatasha

TABLE 1-3 Condition vs. Translation

Translated Packet Service is ...

Original Packet

Service is ... Original

Any no conditions on Service,and Service is nottranslated

invalid combinationSecurityPolicy will not verify

the rule applies only to

packets whose Service is, andService is not translated

the rule applies only to packets

whose Service is ,and is translatedto

Note Routing tables on the gateway and router may have to be modified to implementNAT (see Address Translation and Routing on page 29).


Rule 2


42/272


The second rule in FIGURE 1-20 (a Static Source Mode rule) specifies that:

Condition when the original packets Source address is in the address range

IllegalAddresses

Action translate its Source address to the corresponding address in the addressrange LegalAddresses

Rule 3

The third rule in FIGURE 1-20 (a Static Destination Mode rule) specifies that:

Condition when the original packets Destination address is in the address

range LegalAddresses

Action translate its Destination address to the corresponding address in theaddress range IllegalAddresses

Rule 4

The fourth rule in FIGURE 1-20 specifies that:

Condition when the original packets Service is in the service rangeStandardPorts and its Destination is DMZ-Servers

Action translate its Service to the corresponding Service in the service rangeNonStandardPorts

Compound Conditions

Conditions underOriginal Packet are ANDed together. For example, the fourth rule inFIGURE 1-20 has a compound condition, that is, there are two conditions to be met,both of which must be true in order for the rule to apply.

The two conditions are:

1 The original packets service number is in the service range StandardPorts.

2 The original packets Destination is DMZ-Servers.

Multiple Translation

If the addresses in two internal networks are invalid, there may be problems incommunications between the two networks (see Gateway with Three Interfaces onpage 55 for further information), which arise because both the source and destination

addresses of packets must be translated.

Note The first three rules in this example can be automatically generated by the methoddescribed in Generating Address Translation Rules Automatically on page 37. The last rulecannot be automatically generated.

Defining Address Translation Rules

The GUI allows the specification of multiple translations in a single rule. For example,FIGURE 1 21 shows a rule in which both the source and destination addresses of


43/272


FIGURE 1-21 shows a rule in which both the source and destination addresses ofpackets are translated.

FIGURE 1-21 Multiple Translation rule

For a detailed example of when a rule like this is necessary, see Gateway with ThreeInterfaces on page 55.

Defining Address Translation Rules

Before defining a NAT rule, you must first define the objects that will be used in the

rule.UnderSource and Destination, you can use any Machine or Network network object,including groups and Address Range objects.

UnderService,you can use any TCP or UDP Services object, including groups and PortRange objects.

Warning FWZ encryption cannot be used for connections in which both the source anddestination IP addresses are (NAT-translated. For information about FWZ encryption, seeChapter 6, Implementing FWZ Encryption of Check Point Virtual Private NetworksGuide,

Note Routing tables on the gateway and router may have to be modified to implementNAT (see Address Translation and Routing on page 29).


Using the NAT Rule Base Editor
http://../VPN/VPNFWZ.pdfhttp://../VPN/VPNFWZ.pdfhttp://../VPN/VPNFWZ.pdfhttp://../VPN/VPNFWZ.pdf


44/272


To display the NAT Rule Base Editor (FIGURE 1-22), select the Address Translation tabin the Rule Base Editor.

FIGURE 1-22 Address Translation Rules Editor

To return to the Rule Base Editor, select the Rule Base tab.

The NAT Rule Base is part of a Security Policy. If you have more than one Security

Policy, then each of them can have a corresponding NAT Rule Base. The NAT Rule Baseis installed when the Security Policy is installed.

Editing a NAT Rule Base

Adding a Rule

You can add a rule at any point in the NAT Rule Base, except between automaticallygenerated rules.

TABLE 1-4 Adding a Rule

To add a rule Select from menu Toolbar Button

after the last rule RuleAddBottom

before the first rule RuleAddTop

after the current rule RuleAddAfter

before the current rule RuleAddBefore


A new rule will be added to the NAT Rule Base, and default values will appear in allthe data fields. You can modify the default values as needed.


45/272


the data fields. You can modify the default values as needed.

Modifying a Rules Data Fields

To modify a data field in a rule, right click on the value. A menu will be displayed,from which you can choose the new value.

Original Packet Source

Source can consist of only one object. The types of objects allowed forSource underOriginal Packet depend on what is specified forSource underTranslated Packet, aslisted in TABLE 1-5.

AddThe Object Manager window (FIGURE 1-23) is displayed, from which you canselect a network object.

FIGURE 1-23 Object Manager window

ReplaceThe Object Manager window (FIGURE 1-23) is displayed, from which you canselect an object to replace the object currently in the rules Source.

EditEdit the object in the rules Source.

The appropriate window is opened (depending on the type of the selected object),and you can change the objects properties.

DeleteDelete the object currently in the rules Source.

CutDelete the object currently in the rules Source and put it on the clipboard.

CopyCopy the object currently in the rules Source to the clipboard.

PastePaste the object on the clipboard in the rules Source.

Note To select a rule or rules, select their numbers.

TABLE 1-5 Original Packet - Source

If Translated Packet - Source is ...

Original Hide Static

Original Packet -Source can be ...

Machine, Network,Address Range or agroup of one ofthese

Machine, Network,Address Range or agroup of one ofthese

Machine, Network,Address Range butnot a group


Original Packet Destination
http://-/?-


46/272


Destination can consist of only one object. The types of objects allowed forDestinationunderOriginal Packet depend on what is specified forDestination underTranslatedPacket, as listed in TABLE 1-6.

AddThe Object Manager window (FIGURE 1-23) is displayed, from which you canselect a network object.

ReplaceThe Object Manager window (FIGURE 1-23) is displayed, from which you canselect an object to replace the object currently in the rules Destination.

EditEdit the object in the rules Destination.

The appropriate window is opened (depending on the type of the selected object),and you can change the objects properties.

DeleteDelete the object currently in the rules Destination.

CutDelete the object currently in the rules Destination and put it on the clipboard.

CopyCopy the object currently in the rules Destination to the clipboard.

PastePaste the object on the clipboard in the rules Destination.Original Packet Service

Services can consist of only one object. The types of objects allowed forServices underOriginal Packet depend on what is specified forServices underTranslated Packet, aslisted in TABLE 1-7.

TABLE 1-6 Original Packet - Destination

If Translated Packet - Destination is ...

Original Hide Static

Original Packet -

Destination can

be ...

Machine, Network,Address Range or agroup of one of these

Machine, Network,Address Range or agroup of one of these

Machine,Network,

Address Range

but not a group

TABLE 1-7 Original Packet - Services

If Translated Packet - Services is ...Original Hide Static

Original Packet -

Services can be ...TCP, UDP, Range orgroup of one of theabove

TCP, UDP, Range orgroup of one of theabove

TCP, UDP,Range but not agroup


AddThe Services window (FIGURE 1-24) is displayed, from which you can select aservice.


47/272


FIGURE 1-24 Services window

ReplaceThe Serviceswindow (FIGURE 1-24) is displayed, from which you can selectan object to replace the object currently in the rules Services.

EditEdit the service.

The appropriate window is opened (depending on the type of the selectedservice), and you can change the services properties.

DeleteDelete the object currently in the rules Services.

CutDelete the object currently in the rules Services and put it on the clipboard.

CopyCopy the object currently in the rules Services to the clipboard.

PastePaste the object on the clipboard in the rules Services.

Translated Packet Source

Source can consist of only one object. The types of objects allowed forSource depend

on the type of Address Translation, as listed in TABLE 1-8.

TABLE 1-8 Translated Packet - Source

If the Address Translation is

Hide Static

Translated Packet -

Source can be ...Machine, Network, or Rangeof same size as OriginalPacket - Source

Machine, Network, Router, orRange of size 1
http://-/?-http://-/?-


48/272


Translated Packet Destination

Destination can consist of only one object The types of objects allowed for Destination


49/272


Destination can consist of only one object. The types of objects allowed forDestinationdepend on the type of Address Translation, as listed in TABLE 1-9.

Add (Static)The Object Manager window (FIGURE 1-23 on page 45) is displayed,from which you can select a network object.

The Destination object underOriginal Packetwill be translated to DestinationunderTranslated Packet, in Destination Static Mode.

Replace (Static)The Object Manager window (FIGURE 1-23 on page 45) is displayed,from which you can select an object to replace the object currently in the rulesDestination.

Replace (Static) is only available when the Destination object was added byAdd(Static).

EditEdit the Destination object.

The appropriate window is opened (depending on the type of the Destinationobject), and you can change the objects properties.

DeleteDelete the object currently in the rules Destination.

After you delete the object, Destination is set to Original.

CutDelete the object currently in the rules Destination and put it on the clipboard.

After you cut the object, Destination is set to Original.

CopyCopy the object currently in the rules Destination to the clipboard.

PastePaste the object on the clipboard in the rules Destination.

Translated Packet Service

Service can consist of only one object. The types of objects allowed forService are:

s TCP

s UDP

s Port Range

Add (Static)The Servicewindow (FIGURE 1-24 on page 47) is displayed, from which

you can select a network object.

TABLE 1-9 Translated Packet - Destination

If the Address Translation is

Hide Static

Translated Packet -

Destination can

be ...

Machine, Network, or Rangeof same size as OriginalPacket - Destination

Machine, Network, Router,or Range of size 1


The Service object underOriginal Packetwill be translated to Service underTranslated Packet.


50/272


Replace (Static)The Services window (FIGURE 1-24 on page 47) is displayed, fromwhich you can select an object to replace the object currently in the rules Service.

Replace (Static) is only available when the Service object was added byAdd(Static).

EditEdit the Service object.

The appropriate window is opened (depending on the type of the Service object),and you can change the objects properties.

DeleteDelete the object currently in the rules Service.

After you delete the object, Service is set to Original.

CutDelete the object currently in the rules Service and put it on the clipboard.

After you cut the object, Service is set to Original.

CopyCopy the object currently in the rules Service to the clipboard.

PastePaste the object on the clipboard in the rules Service.

Install On

The Install On field specifies which FireWalled objects will enforce the rule. You cannotchange the Install On field for automatically generated rules, but you can change it formanual rules.

To modify the Install On field, right click on it. A menu is displayed, from which youcan select one of the values listed in TABLE 1-10.

TABLE 1-10 Install On Menu

Install On Meaning

GatewaysEnforce on all network objects defined as gateways.

Integrated FireWallsEnforce on all network objects defined asintegrated FireWalls.

TargetsEnforce on the specified target object(s) only.


Comment

You can add comments to a rule. Double click on the Comment field to open the


51/272


o o o o o o opComment window (FIGURE 1-25).

FIGURE 1-25 Comment window

Type any text you wish in the text box and click on OK.

Copying, Cutting and Pasting Rules

To copy, cut or paste, select a rule or rules by selecting their numbers.

If you choose Paste, then the Paste menu will be opened. You must then select Before,After, Top, orBottom to specify where in the Rule Base to paste the rule.

TABLE 1-11 Copying, Cutting and Pasting Rules

Action Select from menu

Toolbar

Button

Cut EditCut

Copy EditCopy

Paste EditPaste

Address Translation Examples



52/272


Gateway with Two Interfaces

Consider the following network and Address Translation configuration:

FIGURE 1-26 Gateway with Two Interfaces Example - Network

Defining NAT

Since the mailserver accepts and initiates connections, it requires static translation, asshown in FIGURE 1-27.

FIGURE 1-27 mailserver - static translation

Gateway with Two Interfaces page 52

Gateway with Three Interfaces page 55

router

gateway Internet

localnet

mailserver

10.0.0.1

199.203.73.2

public servers

10.0.0.2 10.0.67.1610.0.67.010.0.0.99 10.0.67.1

Gateway with Two Interfaces

Similarly, the Address Range from 10.0.67.0 to 10.0.67.16 is meant to providepublic services, such as HTTP or FTP, to the outside world, and so it too requiresStatic Translation.


53/272


FIGURE 1-28 PublicServers Address Range

These addresses are mirrored as the seventeen (17) addresses from 199.203.73.64 to199.203.73.80. So, for example, when an outside machine sends a packet to IPaddress 199.203.73.70, the packet will actually arrive at 10.0.67.6.

Finally, localnet addresses will be hidden behind the IP address of the gatewaysexternal interface, 199.203.73.2 (FIGURE 1-29).

FIGURE 1-29 localnet Network Properties and NAT tabs


The rules generated from these definitions are shown in FIGURE 1-30.


54/272


FIGURE 1-30 NAT Rule Base

Routing

Assume that the Internet routes IP addresses in the network 199.203.73.0 to the

router.

Then you should ensure that:

1 The router routes IP addresses in the network 199.203.73.0 to the gateway.

2 The gateway routes IP address 199.203.73.3 to the internal interface(10.0.0.1).

3 The gateway routes IP addresses 199.203.73.64 to 199.203.73.80 to theinternal interface (10.0.0.1).

Gateway with Three Interfaces


Hide Mode and Static Mode


55/272



FIGURE 1-31 Gateway with three Interfaces example - network

Suppose we wish to hide all the localnet and DMZ hosts behind the gateway, exceptfor host 192.9.200.9 (HTTPServer), which will be providing public services and somust be accessible from the Internet.

Defining Address Translation

Hiding localnet

To hide localnet addresses, define Address Translation as follows for localnet:

FIGURE 1-32 Hiding localnet

172.45.126.1

172.45.126.41

172.45.126.39

172.45.126.255

192.45.125.4172.45.126.40

192.9.200.1

router

HTTP Server

PrivateNet

Internet

localnet

192.9.200.9192.9.200.2 192.9.200.8 192.9.200.10 192.9.200.255


Hiding PrivateNet

To hide PrivateNet addresses, define Address Translation as follows for PrivateNet:


56/272


FIGURE 1-33 Hiding PrivateNet

HTTPServer

To statically translate HTTPServers address, define its Address Translation as follows:

FIGURE 1-34 Translating HTTPServer


Rules

The rules generated from these definitions are shown in FIGURE 1-35.


57/272


FIGURE 1-35 Automatically generated rules - three interfaces

Note that the Static Mode rules are positioned before the Hide Mode rules.

Communications Between Hosts in Different Internal Networks

The NAT Rule Base works much like the Security Policy Rule Base. The AddressTranslation rules are scanned sequentially, one after the other, until a match is found.The Address Translation indicated by the matching rule is performed, and then thepacket is sent on its way.

Suppose host 172.45.126.47 (in localnet) tries to TELNET to host 192.45.125.209(the valid address of HTTPServer, whose invalid address is 192.9.200.9) inPrivateNet. The first rule that matches is rule 2, so the destination address172.45.125.209 is translated to 192.9.200.9, and the packet arrives at its

destination. The packets source address (172.45.126.47) remains untranslated, sothe reply will be sent to 172.45.126.47 and arrive at its destination.

Routing

Assume that the Internet routes the IP addresses in the network 192.45.125.0 to therouter.

You should ensure that:

1 The router routes the IP addresses in the network 192.45.125.0 to the gateway.

2 The gateway routes IP address 172.45.125.209 to the internal interface(192.9.200.1).


Both Networks Statically Translated



58/272


FIGURE 1-36 Three Interfaces both networks statically translated

Suppose we wish to statically translate the addresses in both networks (localnet andPublicNet). The automatically generated NAT Rule Base is show in FIGURE 1-37.

FIGURE 1-37 Rule Base both networks statically translated

Communications Between Hosts Behind the Same Gateway

Suppose a host in localnet tries to TELNET to a host in PublicNet, using the PublicNethosts valid IP address as the destination IP address. The first rule that applies isrule 3, so the destination address is translated and the packet is correctly routed tothe destination. The reply packets are correctly routed as well, since the source IPaddress is not translated.

On the other hand, suppose a host in PublicNet tries to TELNET to a host in localnet,using the localnet hosts valid IP address as the destination IP address. The first rulethat matches is rule 2, so the source address is translated, but the destination addressis not translated, so the packet will not arrive at its destination.

192.45.125.4192.45.125.5

192.45.125.6

router

PublicNet

Internet

localnet

Gateway

172.45.126.1

172.45.126.255

192.9.200.2 192.9.200.255

Address Translation and Anti-Spoofing

Multiple Translation Rules

One solution is to add two rules before the automatically generated rules as follows:


59/272


FIGURE 1-38 Multiple NAT Rules Added to Automatically Generated Rules

Now, both source and destination IP addresses will be translated, so packets will be

routed to their correct destinations.

Simple Rules

Another solution is to add the same two rules, but to set Source underTranslatedPacket to Original. This solution will work because there is really no need to translatethe source IP address when both networks are connected to the same gateway, whichknows how to route to the internal invalid IP addresses of both networks.

Communications Between Hosts Behind Different GatewaysConsider the case when the internal networks are connected to different gatewayscontrolled from the same Management Server. In this case, both source and destinationIP addresses must be translated, because each gateway knows how to route only to itsown internal invalid IP addresses. Therefore, only the first of the above solutions(multiple translation rules) will work.

Advanced Topics


Anti-spoofing examines the source IP address for incoming packets (entering agateway).

Note In versions of VPN-1/FireWall-1 prior to Version NG, anti-spoofing also examined thedestination IP address for outgoing packets (leaving a gateway).

Advanced Topics

Anti-spoofing is described in Anti-Spoofing on page 177 ofCheck Point ManagementGuide.

Address Translation takes place as follows:
http://../FWSecAdmin/NetObjs.pdfhttp://../FWSecAdmin/NetObjs.pdfhttp://../FWSecAdmin/NetObjs.pdfhttp://../FWSecAdmin/NetObjs.pdfhttp://../FWSecAdmin/NetObjs.pdf


60/272


s for a packet going from the client (the initiator of the connection) to the server,just before the packet leaves the interface closest to the server

s for a packet going from the server to the client, just after the packet enters theinterface closest to the server

Automatically Generated Rules

You do not have to do anything to ensure that anti-spoofing is performed correctly forthose objects for which you generate Address Translation rules automatically.

This remainder of this section describes anomalies which must be considered when youdefine Address Translation manually. The examples illustrate the interaction betweenAddress Translation and Anti-Spoofing for each of the Address Translation modes.

Note If Perform destination translation on the client side in the NAT tab of the GlobalProperties window is not enabled, then even for automatically-generated NAT rules, youmay need to add the translated addresses to the internal interfaces Valid Addresses. SeeStatic Destination Mode on page 63 for more information about this case.


Hide Mode

FIGURE 1-39 on page 61 shows a gateway performing both Address Translation (in HideMode) and Anti-Spoofing on a packet and its reply as they pass through the gateway.


61/272


FIGURE 1-39 Address Translation and Anti-Spoofing (Hide Mode)

Conclusion

In Hide Mode, there is no conflict between Address Translation and Anti-Spoofing.

TABLE 1-12 Address translation and Anti-Spoofing (Hide Mode)

external interface internal interface

original packet

Anti-Spoofi

Documents

Check Firewall-1 Guide